GC architecture for backends

[Chris]

I would suggest that those wishing to use a database other than SQLite
will have to know what they are doing so can define the DSN externally
and so when opening a book if its name is not in the data source list
create a SQLite DSN and add it to the data source list.

Regards,
Chris
On Thu, 2006-11-02 at 12:47 -0500, Chris Shoemaker wrote:
> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>