postgres development

[Derek Atkins]

Andrew Pimlott <gnucash-devel at andrew.pimlott.net> writes:

> 
> 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).

It's not really a question of normalizing the data -- the problem is
that gnucash has a number of invariants that, AFAICT there is no way
to enforce in a database.

> 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).

Then by all means, use scheme.  Using scheme should be REALLY easy
with the 1.8 codebase -- in fact even "gnucash" is a scheme program!

As for how the scheme code looks, well, the "scheme code" really is is
just wrapped/exported C functions, so it's not at all surprising that
it could segfault.  It tries not to do so, and if you do find places
that segfault it should be reported as a bug (all exported C functions
should check their arguments).

Admittedly the API documentation is out of sync; but you can look for
gw-*.html within the build tree for all the g-wrapped functional
documentation.

> 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.

Well, it all depends -- are you sure your data is stored in SQL?  Are
you completely writing off people who use the XML/File backend?  Or
the RPC backend (even if it doesn't work)?  Or....

> 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.

I would hope so.  The Engine Library is extremely standalone.  You
should be able to pull in the engine, app-utils, and backend modules
without pulling in any UI functions.  If this is not the case, then
it's a critical (IMHO) bug and needs to be fixed.

> 1ndrew

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available