postgres development

[Andrew Pimlott]

On Mon, Mar 03, 2003 at 10:36:20PM -0600, Matthew Vanecek wrote:
> On Mon, 3 Mar 2003, Andrew Pimlott wrote:
> 
> > I've seen messages that at least one person is working on a redesign
> > of the postgres back-end.  (I didn't check who, but I assume he's on
> > the list.)  I'm thinking about a little project that would like to
> > interface with gnucash at the data level; ie, talk to the database
> > rather than use the gnucash API.  If anyone working on the postgres
> > back-end has any concrete plans for it, I would appreciate hearing
> > about them.  Perhaps I could offer some assistance as well.
> > 
> 
> That probably is not a good idea, unless you are just going to use the 
> database and no other part of Gnucash.  It's unsafe design--you could 
> easily munge the data.

I would hope that the data model would be sufficiently normalized
and constrained to make direct access reasonably safe.  I consider
this is an entirely reasonable goal (and as I said, I would be
interested in helping).

I am not (currently, at least) concerned with running my program
concurrently with gnucash, so that is not an issue.  (Though
hopefully it could be addressed if needed.  I realize that coherency
between gnucash and the database is tricky.)

> Is there some reason you cannot use the Engine 
> API?  That would be a far better direction, and the Engine API is pretty 
> well defined and separated from the GUI.

I have tried and unfortunately ran into difficulties.  I would much
prefer to use Scheme than C, however the Scheme bindings do not seem
to be very well maintained (aside from the parts needed for
reports), and are at any rate very C-like (sometimes they would even
seg-fault :-) ), which makes them less pleasant to use.  And when I
tried to use some functions outside the engine, I found that they
made assumptions about running under the UI.  (I know, this all
could be fixed, but it seems like a big job, and I don't think I
want to do it.)  Last, much of the API is undocumented, or the code
has evolved apart from the documentation (from what I could tell
perusing the src/doc directory).

Maybe I will go back and give it another shot, but my early efforts
were slow going.  This led me to decide that talking SQL would be
easier.

I don't mean to be too critical: the engine is indeed well separated
and is clearly, at the core, a clean design.  But I have to admit
that when I look at a function starting xacc and see a bunch of
calls starting gnc_, I wince a bit.

1ndrew