On Mar 19, 2012, at 8:03 PM, James Nylen wrote: > I don't have a demo set up. I will let you know if I can get something > working, but there are a lot more features I'd like to implement (graphs, > budgeting, etc.) so it would probably be after I can get some of those > working. > > I currently use the GnuCash API for importing QIF files via a cronjob, and > that's the only place. It certainly takes longer than would be acceptable > for a web request, but that's partly because I'm doing some things to > eliminate duplicate transactions. > > The only modifications I make from Django are to change the opposing > account of a transaction. How bad is that, or how likely is it that I'm > not modifying important data stored in the key/value table? > > Also, I noticed that GnuCash deletes tables it doesn't recognize. This > means I'm using a separate database for the Django stuff, which is less > convenient because Django doesn't support cross-database foreign keys. Any > idea why GnuCash deletes tables like that?
Gnucash isn't a database program. It initializes a dataset by loading everything from the database into memory and working with the in-memory objects. It also suffers from poor data hiding, with classes getting in each others knickers and altering member variables behind the owning class's back. In cases like that it can't do an incremental save (because the class that would do the save doesn't know it's been changed), so it saves everything. It does that by renaming all of the tables to a backup name -- and it does that by getting the table and index lists from the database -- then writing a new database, then dropping all of the backup tables. That's all done under database transaction control so that it can be rolled back if anything goes wrong, but the bottom line is that any non-Gnucash tables in the database will get dropped. That will eventually change after we get the object design fixed and implement a proper transactional interaction with the database. Eventually in this case means several years. Even then I don't foresee guaranteeing that Gnucash won't remove foreign tables from its database. Our party line on writing to the database is that it's only safe if done by the Gnucash API. For a simple cash transaction, changing a split's account is probably harmless (assuming that it makes sense, of course). That's not always the case if the split is part of a lot or a business operation (paying a bill, for example) because the data isn't normalized -- the account reference may be duplicated somewhere. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
