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 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
