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 <[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 > > 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
