QOF-to-SQL Proof of Concept
linas at linas.org
Wed May 26 10:07:53 EDT 2004
On Mon, May 24, 2004 at 11:10:49AM -0400, Derek Atkins was heard to remark:
> linas at linas.org (Linas Vepstas) writes:
> > FYI,
> > I just finished coding a proof-of-concept for saving & restoring
> > arbitrary QOF objects to SQL tables & back. I've now started on
> > a prototype that will 'do it correctly' i.e. mutate into the final
> > version. You probbly don't want to look at the code, since its
> > 'all wrong', but its in the dwi.sourceforge.net CVS tree, in
> > the 'examples/basic-qof' directory. The prototype that was just
> > started is in 'examples/qof-proto'.
> Cool!! I can't wait to see this proof-of-concept hit Gnucash. :)
Don't gocrazy hjust yet, wait for the prototype to get finished.
There's still a lot of work left.
> Question: What process are you using for cache coherency between the
> QOF ram cache and the SQL backend? Are you depending on a SQL NOTIFY
> events? Or are you performing a "refresh poll?" I'm hoping it's the
I don't know, I was wondering that myself. BTW seth nickell of
gnome storage is using sql notify and was bitching about the same
thing. I'm like to to steer towards gnome storage, but its in doubt.
> latter, because some SQL engines that I'd like to use don't support
> notify events (e.g. SQLite).
but SQLLite is single-user, right? No multi-user support.
> > Anyone have any brilliant ideas on how to manage user logins &
> > permissions & etc?
... OK ...
> Another thing that we should fix: username and password information
> should NOT be in the book URL. This get's translated into a filename
> and stored in ~/.gnucash/books/ which basically publishes your SQL
I was assuming that some hacker out there would say 'wow, let me
write a login/passwd dialog for you', but clearly that never happened.
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