QOF-to-SQL Proof of Concept
listas at enlar.net
Mon May 24 14:09:15 EDT 2004
I think it should be optional to store the user/password for database
access, for maximun privacy; like with the web navigator and login
forms. If not stored (gconf or whatever), Gnucash should ask for it
every time user opens the book.
My 0.01 eurocent ;)
P.D.: Keep on your excelent work!
El lun, 24-05-2004 a las 17:10, Derek Atkins escribió:
> 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. :)
> Nice work!!!
> 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
> latter, because some SQL engines that I'd like to use don't support
> notify events (e.g. SQLite).
> > Anyone have any brilliant ideas on how to manage user logins &
> > permissions & etc?
> I would leave that up to the database... Provide a login dialog when
> opening the book and "login" to the database (maybe make this
> dependent of the actual database in use? E.g. SQLite probably doesn't
> need it). Then just use the database's permission model to protect
> the data.
> We might be able to get more clever and use per-table acls to control
> which portions of the data a particular user has access to. But I
> think this is going to depend greatly on what the underlying db can
> 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
> username and password. Not a good idea. Either we shouldn't cache
> that information at all, or it should get stored in GConf or some
> other "private" data source. Just my $0.02 (riddled with some
> feedback from a few users on IRC).
> > --linas
More information about the gnucash-devel