sqlite file format, anyone?

Matthew Vanecek mevanecek at yahoo.com
Sun Jun 22 22:14:55 CDT 2003


On Sun, 2003-06-22 at 14:30, Derek Atkins wrote:
> linas at linas.org (Linas Vepstas) writes:
> 
> > On Sun, Jun 22, 2003 at 02:49:40PM -0400, Derek Atkins was heard to remark:
> > > linas at linas.org (Linas Vepstas) writes:
> > Well, but that's kind of how the pg backend works currently.  In most
> > cases the SQL 'NOTIFY gncSplit;' messages gets turned into a
> > GNC_EVENT_DESTORY.  And there's specialcase code for dealing with 
> > two GUI's editing the same split at the same time.  So the events
> > are already there, and I think you still need to have the specialcase 
> > code.
> 
> Except it's not very real-time (the client has to emit a query
> to notice the event), and it's not very portable (it requires
> pg).
> 

The libpq library is documented to be thread-safe, so I could put the
notify polling in a fork(), using select() or pselect(), and have it
generate a signal when it receives a notification.  Pretty simple to
accomplish in theory, but would require some signal handling
architecture.  Doesn't take up any extra CPU cycles, either.

> I'm still up in the air about whether ONC-RPC is the right solution to
> this problem, vs. XML-RPC/SOAP or perhaps some other (home grown)
> network protocol.  I also admit that it does move the problem
> somewhere else, moving the "serializing" problem into gnucashd.  I'd
> have to really sit down and think about it longer.
> 

I think that it's best to use standard protocols where possible.  It's
more portable, the learning curve is shallower for new developers, and
it's easier to maintain.

> While I really want to see a standalone SQL engine embedded into the
> client to replace XML, I don't know how much effort I want to extend
> personally to work towards real multi-user support.  If it just falls
> out of Matthew's work, great.  OTOH, if it would reduce the wait-time
> by 6 months to go forward without multi-user, I'm all for going ahead
> without it.

The SQL back end should be inherently multi-user.  There's a certain
amount of checking that can theoretically be safely skipped in a single
user environment, but that's skipping I plan on adding later.  For the
moment, it's a multi-user architecture.  For me, this is mainly a
difference at the very lowest levels.  The upper layers shouldn't care
what type of access is being used (other that storing it in the Backend
object).


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