On Sat, Jun 21, 2003 at 01:51:56PM -0400, Derek Atkins was heard to remark: > > uggh... yet another dependency!?! (odbc) If we're going down that > route we might as well just use libdbi (libdbi.sourceforge.net) which
:-() libdbi is fine w/ me. It looks like a cleaned up version of ODBC. FWIW, generic object support might (or might not) require ability to handle meta-queries, e.g. 'what are the names of all the tables in this db' or 'what are the names and types of all the fields in this table', which odbc supports, and it doesn't look like libdbi does. (this can be worked around, at least in postgres, which allows things like 'select * from pg_tables;') The ODBC 'connection' model stinks, it requires that the user supply some sort of convoluted abstracted server/database names instead of a simple URL. Also, the tools to set these up and configure them are confusing. Again, legacy of a pre-WWW microsoft design decision. > is at least lightweight. RH9 already ships with libdbi-0.6.5 and Its in debian too, so that's fine by me. Sorry about the dependencies. > Updating multiple tables at once just requires transaction support, > no? What else besides transaction support do you need? well, for starters, you have to specify *which* tables to update at the same time: e.g. transaction and split but not account or price or commodity. So, from the generic-object point of view, this counts as 'additional complexity'. Also, you need to specify how the tables are connected, i.e. you have to match guids: 'update gncTrans, gncSplit where trans.guid=split.guid' so again, some additional complexity. It might be enough to assume that for generic objects, all chaining together is done with guids. Also, kvp presents some additonal complexity. > Multi-user > updates is an issue because of how GnuCash caches data in the engine > instead of relying on the backend all the time. If GnuCash was > just a SQL app and didn't cache data locally then we wouldn't have > this problem, either -- every "refresh" would pull fresh data > from the database. Admittedly, I don't know how to do 'events' > generically in a SQL application. in postgres, you can broadcast an 'event' which can be any string (typically a table name), and anyone 'listening' would get it. For the sql backend, I added a version number so that every 'refresh' does *not* go to the db; it only goes to the db if it received an event and if the version number changed. Its not hard per se, its just that many more KLOC's to write and debug. Again, that's why the sql backend got so large ... > But yea, > renaming the functions would probably be best, even if it means more > work keeping everything in sync. Or you can just write a PERL script > that does the renaming. That might be easier. OK. Should the prefix be 'qof' or 'gnc'? I propose using the same capitalization and dash-underscore conventions as gnome does. Or do you prefer something different? Also, its not to late to chage the 'qof' name if you are interested. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
