QOF-to-SQL Proof of Concept

Derek Atkins warlord at MIT.EDU
Mon May 24 14:09:38 EDT 2004

Agreed, I guess I didn't make that clear in my initial mail.


Eneko Lacunza <listas at enlar.net> writes:

> 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

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list