On Sun, Jun 22, 2003 at 09:14:55PM -0500, Matthew Vanecek was heard to remark: > > The SQL back end should be inherently multi-user. There's a certain
I've sort of lost track as to why we need to redesign the pg backend 'from scratch' instead of migrating it, bit by bit, to a more flexible design. I personally tend to beleive in the 'migrating' way of developing: at any given instant in time, you still have a system that works, that's not broken, which means you can take a vacation at any time without the guilt of leaving behind something broken. The other benefits of 'migrating' is you benefit from years of bug fixes and from important design changes that can be hard to re-invent from scratch. The obvious ways of 'migrating' the pg backend would be: -- change it to use libdbi -- modify the event code so that if db==pg, then use old event code, else use pseudo events taken from a table that is polled. -- Disable the balance checkpointing subsystem if db!=pg -- Implement 'setters' so that the business objects can be 'trivially' added. -- For embedded-MySQL, skip all of the multi-user code. There is a single-user mode in the pg backend, and I could probably show you how to further simplify it. >From where I sit, it seems like a 'redesign from scratch' effort has a real high risk of loosing. --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
