sqlite file format, anyone?
Linas Vepstas
linas at linas.org
Sat Jun 21 23:54:21 CDT 2003
On Sat, Jun 21, 2003 at 10:07:18PM -0400, Derek Atkins was heard to remark:
> Matthew Vanecek <mevanecek at yahoo.com> writes:
>
> > I was going to use gncVersion for that... Linas is referring, however,
> > to system tables vs. Gnucash tables. Each DBMS is a little
> > different--DB2 puts stuff in SYSIBM.*, Postgresql uses the pg_* tables,
> > etc. That's what would be difficult about a generic object interface
> > when trying to access system information.
>
> Ok, call me stupid, but why would one need to access "system tables"?
If you wanted to build a database browser, of course!
(Not that we need on in gnucash, or in QOF (yet) ...
> > KVP tables.
I'm going to play dumb for a moment. What's wrong with storing the
triplet (keypath,value,guid-of-parent) where 'keypath' is the
slash-delimited list of keys?
> > go backwards (i.e., refer back to *whatever* table from the KVP table
> > based on the GUID).
Wouldn't this be solved by (keypath,value,guid-of-parent,type-of-parent)?
> > > > in postgres, you can broadcast an 'event' which can be any string
> > > > (typically a table name), and anyone 'listening' would get it.
> > >
> > > Hmm, ok.. How do you set this up?
see src/backend/postgres/events.c
The listener does a "LISTEN gncPrice;"
The sender does 'NOTIFY gncPrice;'
That code also uses the 'audit trail', and this is important: if one
client has deleted a specific split, one has the potential tricky
situation that the other side will conclude that its copy of the split
is "new", and so it adds it right back in. I avoid this by having
the other client check the audit trail before assuming that it has a handle
to a new, rather than a deleted split.
> > >I dont know if there is a good
> > > way to go this generically. I don't know if MySQL or SQLite have
> > > events, or if they do I have no clue how to set them up.
They're only needed for multi-user. The embedded mysql backend is
single-user.
> Ok, what do you register for? Do you register for a particular row
> in a table? Or register for a table? Or register for something else?
If I remember correctly, you can register for any string, although typically
the string is a table name. The listener must know the string in advance.
You can't really pass any data this way. You can only make 'event x' happen;
if you want to pass data, you pass it in a table.
> > I'm hoping my version of the PG backend is pluggable enough that you can
> > just plug-n-play the db access code. The bulk of the work is in the
> > Query decoding and Engine loading.
I'm going to strongly disagree with this. Unless I misunderstand the
statement. I did the 'obvious generalizations' as m4 macros (maybe not
a good technology choice, but it was worth a shot). But there's a
huge amount of code that's not m4 macros. Its very specific, and its
really needded to make things work correctly.
I initially thought that 95% of the code would be generic m4 macros,
just 'query decoding and engine loading' but that turned out be not
the case; maybe only 25% is m4 macros.
I vastly underestimated how easy the sql backend would be; the complexity
there was necessity, not frivolity. I'm concerned that you'll trip
over this too ... See? you haven't even started, and already I'm saying
'I told you so' ... :-)
> > Simple things like submitting
> > queries and parsing results are rather easily coded.
builder.c is already completely generic I beleive. Some things like events.c
can probably be chopped up and made generic.
--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
More information about the gnucash-devel
mailing list