On Mon, 2003-06-23 at 12:51, Linas Vepstas wrote: > 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. > > From where I sit, it seems like a 'redesign from scratch' effort has > a real high risk of loosing. >
Because it's not very extensible, it's hard to maintain, the learning curve on it for new developers is steeper than it should be for a DB application... I'm not ripping out the old back end and replacing it with a half-witted half-written morass of code. If someone finds a bug in the existing code, I'll do my best to fix it. It's still going to be there, for now or forever. I prefer the parallel approach. Too often you can become entangled in an existing system and lose sight of new and innovative ways of solving a problem. My approach is to salvage the best parts that fit into my planned architecture, but to still design a new architecture. I take into account the needs of the engine, and the points Derek has brought up (e.g., pluggable modules, etc, for new objects). However, I'm certainly not yanking and breaking the existing code--that'd be pure foolishness at this point. Both back ends can run in parallel for a time, and then the old one can be retired. > --linas -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ******************************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
