sqlite file format, anyone?

Matthew Vanecek mevanecek at yahoo.com
Mon Jun 23 20:35:51 CDT 2003


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...



More information about the gnucash-devel mailing list