postgres development

[Derek Atkins]

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

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

Honestly, I don't know offhand.  I believe that there are places where
you need to guarantee data coherency in multiple places (SQL
transactions?), but I don't know of a way to document that dependency
in SQL.  I'd have to think about how to enumerate the invariants,
but I don't have the time to think about that right now.  I barely
have enough time to fix real bugs....

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

Uh, gw-engine-spec.scm is CERTAINLY not a "get the GUI running" API.
You can do something like:

gnucash-env guile
guile> (use-modules (gnucash gnc-module))
guile> (gnc:module-load "gnucash/engine" 0)
#<gw:wcp <gnc:module> 0x807bd40>
guile> (define s (gnc:session-new))
guile> (define b (gnc:session-get-book s))
guile> (define a (gnc:malloc-account b))
guile> a
#<gw:wcp <gnc:Account*> 0x809aba0>
guile> 

I've just created a new session, and I just created a new account
within that session.  Granted, I now need to set all the parameters of
the account (name, commodity, etc), and stick it into the account
hierarchy...

However, I see no GUI here at all.  Do you?

I admit that a lot of the higher-level functions are there to "get the
GUI running".  We probably do need to separate out the "get the GUI
running" from the "initialize the engine" high-level APIs.  You certainly
don't want to use (gnc:main) :)

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

Please.  Are these problems with 1.8?  Or probably you had in the
past?  If the latter, can you please verify that it's still a problem
with 1.8 before adding it to the list?

-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