On Thu, 2006-02-11 at 08:40 -0600, Daniel Espinosa wrote: > 2006/11/1, Derek Atkins <[EMAIL PROTECTED]>: > > Quoting Daniel Espinosa <[EMAIL PROTECTED]>: > > > > >> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
