RE: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)

2005-04-04 Thread Dittmar, Daniel
>From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Ian Bicking > After that it's >potentially entirely up to the database driver, though of course some >uniformity is nice. Typical DSNs, from what I can tell, are parsed in >an up-front manner into a set of keys and values; though

Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)

2005-04-04 Thread M.-A. Lemburg
Dittmar, Daniel wrote: >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Ian Bicking >>After that it's >>potentially entirely up to the database driver, though of course some >>uniformity is nice. Typical DSNs, from what I can tell, are parsed in >>an up-front manner into a se

RE: [DB-SIG] URI syntax for database

2005-04-04 Thread Dittmar, Daniel
>pydbapi-mx.ODBC.Windows://:@sqlserver.example.com/?DA >TABASE=test > >Looking at this URI I don't think that the URI-approach is >going to make things any easier for the user in setting up >things. If I understood Ian right, he doesn't wants to improve on import dbmodule session = dbmodule.connec

RE: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLiteconnection - relative filename)

2005-04-04 Thread Vernon Cole
Ummm... a little caution here. Don't get comfortable assuming that ODBC is a dependable measure of how to access a data base.As is typical of Micro$oft, and many other companies which have grown too large and self-important, they have changed the rules. ODBC, having become an industry quasi-st

Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)

2005-04-04 Thread Ian Bicking
Dittmar, Daniel wrote: Of course, following that pattern you could get dbapi:jdbc:postgresql://... which feels awfully weird to me. a) I'd prefer pydbapi: as a prefix. That way, someone looking at a configuration file could at least get the notion that any problems might be related to some Python

Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)

2005-04-04 Thread Ian Bicking
M.-A. Lemburg wrote: c) Should username and password be used similar to other protocols? pydbapi:://[:@][: / This is not URI conformant (AFAIK): you cannot have multiple schemes separated by colons. pydbapi-://... Well, I think it's up to scheme to parse the rest of the URI, so the scheme would

Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)

2005-04-04 Thread Andy Dustman
I vote for: pydbapi-://[[:[EMAIL PROTECTED][:]]/[][?param1=...¶m2=...] Where: dbms: Name of the database server implementation (mysql, postgresql, oracle, etc.); map server implementation names to callables (factory functions) that should be passed a mapping of all the above parameters and retu

Re: [DB-SIG] URI syntax for database

2005-04-04 Thread Ian Bicking
Andy Dustman wrote: I vote for: pydbapi-://[[:[EMAIL PROTECTED][:]]/[][?param1=...¶m2=...] Where: dbms: Name of the database server implementation (mysql, postgresql, oracle, etc.); map server implementation names to callables (factory functions) that should be passed a mapping of all the above pa

[DB-SIG] Re: Looking for Stephen Turner, maintainer of informixdb

2005-04-04 Thread Carsten Haese
On Tue, 2005-03-29 at 03:05, Michael Husmann wrote: > Carsten Haese wrote: > > > Hello everybody: > > > > I have discovered that the functionality for connecting Python to an > > Informix database is currently in a frustrating state of neglect. The > > link to Kinfxdb is dead, and informixdb does

Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLiteconnection - relative filename)

2005-04-04 Thread M.-A. Lemburg
Vernon Cole wrote: > Ummm... a little caution here. Don't get comfortable assuming that ODBC > is a dependable measure of how to access a data base.As is typical > of Micro$oft, and many other companies which have grown too large and > self-important, they have changed the rules. ODBC, having