Graham Leggett <[EMAIL PROTECTED]> writes: > We should be very careful of coding workarounds in gnucash to "fix" > limitations in libgda. Time passes, libgda is fixed, and suddenly our > "fix" becomes our bug. > > We should rather sanity check the backend when we start, to make sure > that certain basic sane defaults are supported. For example, we might > (and probably should) require prepared statement support. If prepared > statement support is missing for that backend, that backend should be > greyed out (with some hint to the user as to why). > > Then - as soon as libgda releases a backend that fits our > requirements, gnucash suddenly supports that backend. > > This is significantly safer in the long term.
Except SQLite is a requirement. If we can't support SQLite then IMNSHO the project has failed. So by that, if we have to make a workaround to get SQLite working, we should. Note that we can always key the workaround code based on the version of gda we find when we build gnucash. > Regards, > Graham -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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel