postgres development

Andrew Pimlott gnucash-devel at andrew.pimlott.net
Wed Mar 5 14:03:21 CST 2003


On Wed, Mar 05, 2003 at 10:58:48AM -0500, Derek Atkins wrote:
> 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 expect you can find a way to enforce most of them in the database,
although it may be awkward in SQL, and you would be duplicating the
same constraints in the code.  But how onerous are these invariants?
Obviously, splits must balance, and there are probably (?) some
limitations on which kinds of splits can go in which kinds of
accounts.  Am I missing a lot?

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

(But it seems to use an API that is geared towards "get the GUI
running", so that part isn't very useful to me.)

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

I'll collect some of the problems I had in another posting.

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

As a small aside, I found it really annoying not to have tags
support for the g-wrappers.  I managed to hack it via what little
extensibility exists in exuberant-ctags.  So I can just do a tag
lookup on gnc:session-get-book and see the documentation.  (I assume
the strings in gw:wrap-function are what you mean by the gw-*.html
documentation; in my build, those are length 0 files, so I must be
missing some tool.)  Very handy.

My ctags script looks like

    ctags --recurse
    find -name '*-spec.scm' |
        xargs ctags --append --langmap=scheme:.nonesuch \
                    --langdef=g-wrap --langmap=g-wrap:'(*-spec.scm)' \
                    --regex-g-wrap="/'(gnc:[^[:space:]]*)/\1/f,functions/e"

("make tags" spits out a whole bunch of garbage for me, so I didn't
try to figure out how to work this into the build process.)

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

Well, this is just a personal project for now.  And I also think the
SQL backend is a good long-term direction for Gnucash, so I'm happy
to promote it.  :-)

Andrew


More information about the gnucash-devel mailing list