sqlite file format, anyone?

Linas Vepstas linas at linas.org
Sun Jun 22 15:09:39 CDT 2003


On Sun, Jun 22, 2003 at 02:49:40PM -0400, Derek Atkins was heard to remark:
> linas at linas.org (Linas Vepstas) writes:
> 
> > OK, what I was thinking of was more along the lines of having something like:
> > 
> > static LoadObjectDef setters[] = {
> >     { ACCOUNT_NAME_, LOAD_STRING, (Setter)xaccAccountSetName },
> >     { ACCOUNT_DESCRIPTION_, LOAD_STRING, (Setter)xaccAccountSetDescription },
> >     { ACCOUNT_NOTES_, LOAD_STRING, (Setter)xaccAccountSetNotes },
> > };
> 
> Ahh, I see what you mean here.  I don't think I want the "load-string"
> per se, but adding a "setter" to the object definition would be a
> reasonable first step.


OK, Great. Yes, I glossed the details (like 'whats the sql table name',
and etc.) but I'm pretty sure that this is what I really want to have
at the lowest levels.


> > I'm not sure I understand. (I'm not sure I want to). Aren't you just 
> > pushing the problem to a different place?  If one client deleted a 
> > split, another client that's still holding the old split needs to be 
> > able to figure out that it's copy is old, and, at some point, trash 
> > it as well.  You shouldn't have to move megabytes of data across a 
> > wire just to delete one split.
> 
> No, I'm not pushing the problem to a different place.  I'm trying to
> make the problem easier to handle.  If we have a gnucashd sitting
> between the client and the database then we can abstract the event
> handling and get a real-time notification of deletions.  The client
> can get the <GNC_EVENT_DESTROY, Split: GUID> event in real-time and
> know that someone else destroyed the object.

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.

For me, comp sci often seems to be like a hall of transparent walls and
mirrors.  Problems move around but never go away.

I should be careful, I suppose.  By having a gnucashd, the problem does
mutate, maybe into something easier; I can't tell.  I'm not sure I want
to think about it unless you are serious in pursuing that.

--lnas

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


More information about the gnucash-devel mailing list