SQL backend for GnuCash 2

[Derek Atkins]

Benoit Gregoire <bock at step.polymtl.ca> writes:

> Depends what you use them for.  Stored procedure used for additional 
> referential integrity check are not a problem, and saved my ass more time 
> than I can count.  Stored procedures that write to the database and actually 
> implement business logics operations are (generally) not a very good idea.

Fair enough, but that means you need to know what DB you're working
with so you could send it the DB-specific code (or not)..

>> Stored procedures are a double edged sword - very powerful, at the cost
>> of database vendor lockin. For a multi platform application like
>> Gnucash, vendor lockin makes no sense.
>
> What we need is to come up with a comon data model, and a set of features we 
> decide to depend on (ex:  Do we depend on the database supporting cascade of 
> DELETE operations?  Transactions (and to what level)?etc.).
>
> That's our baseline, the code will target that baseline (ie:  note depend on 
> any behaviour not provided by that baseline).  However the opposite should 
> also be true, the code should not depend on specific quiks of that baseline.
>
> Anything above can (and should) be handled for that specific database.

Sure..

I think we absolutely MUST support SQLite, and we SHOULD support
MySQL and PG.  Does someone want to volunteer to find the LCD
features of those three DBs?

I'm not sure what you mean by "cascade of DELETE operations".
I think we CAN depend on the DB supporting transactions, but it
might depend on what level of TXN support we want/need.

-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