sqlite file format, anyone?

[Linas Vepstas]

On Sun, Jun 22, 2003 at 12:55:27AM -0400, Derek Atkins was heard to remark:
> linas at linas.org (Linas Vepstas) writes:
> 
> > Doing real, true multi-user adds to the complexity.  Someone may have
> > changed the transaction the same time you did.  So before you even start
> > writing to the DB, you have to read from it first, and compare to what you
> > had.  If what you had is old, you have to rollback the GUI, and tell
> > the poor user to try again.  Oh, and get the new stuff from the DB. 
> > (Which may be new, modified and/or deleted splits). 
> 
> This is the purpose of beginEdit() -- it should lock the necessary
> database items.  Once the lock is held it can check consistency with
> the current version.

Right. But my point was that its not just a matter of copying from
object to SQL table, and back.  There can be some fairly involved 
algorithms that need have knowledge of the actual accounting objects.
For example, the above complexity is not needed for prices or commodites.
The above complexity is forced by the requirement of 'transaction 
zero-balance' plus 'multi-user ACID consistency'.  If you ditch either,
the complexity goes away.

> This is what transactions are for...  The problem (IMHO) is that
> which objects hold what information is slightly wrong.  For example,
> you begin/commit an ACCOUNT in order to place a Split into the account,
> but it's the Split that needs to know that information.

Yeah, shit happens ... it seemed like the right thing to do at the time.

> Luckily I don't have to think about all the multi-user excess for
> the "XML replacement". 

You can avoid locking and transactions completely, I think.  If you add
setters to gncobject, then I think you just might be able to do things
in a completely generic fashion.  

> My hope is that "balance checkpoints" can coincide with Periods.
> Instead of using stored procedures to compute balances, we merge
> balance checkpoints in with Period support...  And balances are
> computed at Period boundaries.
> 
> It does mean you need to pull in all transactions within a period to
> get proper balances, 

yes, that is correct.

> but honestly I dont consider that a problem.  Do
> you?

Its certainly no worse than the situation for the file backend.
So that's OK with me.

> This approach also means we can toss away the stored procedure mess,
> because balance computation is pushed in when we do period rollover.

Right, you wouldn't need that for the period==checkpoint idea.  
The word 'toss' scares me; the postgres backend does do the scalable,
multi-user thing, I want to keep that, and add the approriate 
generic-object support so that we can more easily get the business 
objects in there, in a scalable, multi-user fashion.

What I'm not clear on is how much Matthew's re-write ends up tossing
the multi-user, scalable, etc. support.   I'm thinking that Matthew
might do best by trying to somehow work with you to do a generic-object
support for the embedded sql backend, that I could back-port to qof
and then make use of in the existing postgres backend to add the 
missing features.  (after I finish Lots :-)

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933