GC architecture for backends

Chris Shoemaker c.shoemaker at cox.net
Thu Nov 2 12:47:50 EST 2006


On Thu, Nov 02, 2006 at 12:25:17PM -0500, Phil Longstaff wrote:
> On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote:
> > 2006/11/1, Derek Atkins <warlord at mit.edu>:
> > > Quoting Daniel Espinosa <esodan at gmail.com>:
> > >
> > > >> Also, we'll need to make changes to handle the fact that file://
> > > >> should get redirected to sqlite:// -- but the code will need to
> > > >> test the file first to see what kind of file it is, so that File -> Open
> > > >> does the "right thing".   I.e., the fact that we're using SQLite
> > > >> should get hidden from the user when we migrate to it.
> > > >>
> > > >
> > > > I think the URI mus be gda:// or db://, think that gda is wrapper for
> > > > many DB backends not just sqlite.
> > >
> > > At some level we need to be able to specify what kind of database is
> > > sitting behind there.  At SOME point we need to know how to specify
> > > a filename for SQLite vs. a host/port/user/password for PG.  So clearly
> > > there's some differentiation there.
> > >
> > 
> > Isn't the case for GDA, when you create a DSN, you can use this name
> > to connect: you just need to specify the DSN, user, password and some
> > options (read only for example) see the libgda.h file where you'll
> > find some convenient functions to easy use GDA and quick do some very
> > common task.
> > 
> > > But this is irrelevant to what I meant.   What the user types into the
> > > File->Open dialog does not need to be the string that gets passed the GDA.
> > 
> > If you have an option to connect or open a DSN the URI could be:
> > 
> > gda://gnucash:username:password
> > 
> > With a gnomedb-login widget you can select a predefined DNS, get
> > username and password, and thats all you can pass it to the QOF beggin
> > session function to open the back end.
> > 
> > 
> > > I'm just pointing out that we need to intercept that input and handle
> > > it appropriately, which may mean adjusting the actual string and perhaps
> > > calling the XML or GDA-with-SQLite backends.
> > >
> > 
> > In the event that GC will use just SQLite or other DB engines, you
> > don't need a special intercept, I think the dialog *must* allways show
> > a gnomedb-login widget to select the DSN, write a user and a password,
> >  and Go!
> > 
> 
> I haven't thought through all of the issues around connections, but I
> don't think we want to use predefined DSNs.  A user shouldn't have to
> set up the GC DSN with an external tool in order to use that DSN within
> gnucash.
> 
> Phil

At least for an initial implementation, I recommend letting the
external tools handle DSN setup.  The most general setups
(i.e. anything other than sqllite) will probably require external
configuration anyway.  Once it's working, we can worry about
streamlining setup for the simple cases.

-chris


More information about the gnucash-devel mailing list