QOF-to-SQL Proof of Concept

Eneko Lacunza listas at enlar.net
Mon May 24 14:09:15 EDT 2004


Hi,

	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
> do.
> 
> 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
> 
> -derek




More information about the gnucash-devel mailing list