RE: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)
>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 maybe they >sometimes include a prefix indicating database type...? DSNs (Data Source Names) are registry keys. The entry for that key contains among other things the id of the ODBC driver. The string for a connect contains the DSN (which is evaluated by the driver manager) and additional connect properties (which are passed to the driver). This at least was the general idea, which has probably been bended since. > Java has >database URIs too, don't they? But they are all like >jdbc:..., correct? Right > 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 lib. b) Using a module path instead of a DBMS product name is generally preferable (and seemed to be the consent so far). With the JDBC scheme, all relevant drivers have to be loaded into memory first, the diver manager then asks each if the driver would accept a specific URI. c) Should username and password be used similar to other protocols? pydbapi:://[:@][: / Daniel Dittmar -- Daniel Dittmar SAP Labs Berlin [EMAIL PROTECTED] ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)
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 set of keys and values; though maybe they
>>sometimes include a prefix indicating database type...?
>
>
> DSNs (Data Source Names) are registry keys. The entry for that key
> contains among other things the id of the ODBC driver. The string for a
> connect contains the DSN (which is evaluated by the driver manager) and
> additional connect properties (which are passed to the driver). This at
> least was the general idea, which has probably been bended since.
The format of ODBC connection strings (sometimes called DSN string
or just DSN) goes like this:
connection-string ::= empty-string[;] | attribute[;] | attribute;
connection-string
empty-string ::=
attribute ::= attribute-keyword=attribute-value | DRIVER=[{]attribute-value[}]
attribute-keyword ::= DSN | UID | PWD | driver-defined-attribute-keyword
attribute-value ::= character-string
driver-defined-attribute-keyword ::= identifier
(taken from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsqldriverconnect.asp;
scroll down to the comments section)
At the very least you have to provide the DSN=
part of the connection string. All other parts are
optional.
>>Java has
>>database URIs too, don't they? But they are all like
>>jdbc:..., correct?
>
>
> Right
>
>
>> 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 lib.
>
> b) Using a module path instead of a DBMS product name is generally
> preferable (and seemed to be the consent so far). With the JDBC scheme,
> all relevant drivers have to be loaded into memory first, the diver
> manager then asks each if the driver would accept a specific URI.
>
> 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-://...
would work, e.g.
pydbapi-mx.ODBC.Windows://:@sqlserver.example.com/?DATABASE=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.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 04 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
RE: [DB-SIG] URI syntax for database
>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.connect () He rather wants to have the possibility to store all the information for a connection in configuration files. Ideally, the controlling program shouldn't need any database driver specific code to create a connection object. The alternative was to call the connect method through keyword args. The controlling program could read the properties out of .ini file, out of XML files, parse a URI or whatever. The problem with that approach was that for some parameters, a string value wouldn't be accepted. So the controlling program would need a way to know which parameters require type conversion. The solution to this one could be that the DB API mandates that connect functions accept strings for all arguments. And until this is implemented, the controlling program has to implement this mapping for each database driver itself. The approach through keyword arguments could have the advantage that it is easier to add some property values at runtime, for example, if the password must be entered interactively. Inserting it into a URI would require some knowledge about the URI format (which is supposed to be database specific). Daniel Dittmar -- Daniel Dittmar SAP Labs Berlin [EMAIL PROTECTED] ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
RE: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLiteconnection - relative filename)
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-standard, is now obsoleted by ADO, the latest in a long series of Microsoft "standards" for database access. One of the best things about ADO, I.M.H.O., is that it does NOT use DSNs or registry entries. The Python dbapi module for odbc on Windows(r) has not been maintained for years and is acknowledged as buggy. The alternative (sorry, Mark) is a commercial product and therefore not usable for many of us. Adodbapi is my solution of choice. --- Vernon Cole -Original Message- ... > DSNs (Data Source Names) are registry keys. The entry for that key > contains among other things the id of the ODBC driver. The string for a > connect contains the DSN (which is evaluated by the driver manager) and > additional connect properties (which are passed to the driver). This at > least was the general idea, which has probably been bended since. The format of ODBC connection strings (sometimes called DSN string or just DSN) goes like this: ... (taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht m/odbcsqldriverconnect.asp; At the very least you have to provide the DSN= part of the connection string. All other parts are optional. ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)
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 lib. I guess... blah, feels like the namespacitus problem of Java, though. b) Using a module path instead of a DBMS product name is generally preferable (and seemed to be the consent so far). With the JDBC scheme, all relevant drivers have to be loaded into memory first, the diver manager then asks each if the driver would accept a specific URI. Yes, it's certainly a problem. For most the module name isn't that bad, though explaining why you have to use MySQLdb: instead of mysql: will be a little annoying, and certainly unsatisfying to the user. I'd feel compelled to create a mapping of aliases, even if I fell back on the module name. There exists the possibility of centrally registering aliases, that is short of importing modules and having them self-register. E.g. put a "db-api-aliases" directory somewhere on sys.path, with filenames like "mysql.txt" that contains "MySQLdb". Maybe multiple lines in a file if there are multiple implementors (and the connector can either bail with a helpful error message about options for being more explicit, or can prefer one driver over another). c) Should username and password be used similar to other protocols? pydbapi:://[:@][: / That was my expectation. Any parameters could also be interpreted as well, like ?autocommit=t&datestyle=mxDateTime -- and so on, which leaves room for any parameters that would be useful. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)
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 be "pydbapi", and it in turn would parse out the module. I think this would be more compliant than: would work, e.g. pydbapi-mx.ODBC.Windows://:@sqlserver.example.com/?DATABASE=test Which really puts something more data-like into the scheme. But then I still prefer using a plain module name, like: mxODBC://user:[EMAIL PROTECTED]/database?params Of course, I do believe it's illegal to have punctuation in the scheme as well... well, I guess not, according to this: http://www.w3.org/Addressing/URL/5_URI_BNF.html While it's nice to be able to find modules given a URI (without preloading any modules) I must admit I am rather reluctant to burden users with what I consider to be internal organizations, like mx.ODBC.Windows, or a particular Postgres driver. 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. Well, I can say that *I* find them very useful and comfortable when configuring SQLObject, even though I initially didn't think they were that important. I suspect that the effect would actually be magnified for someone with less experience using Python database drivers. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLite connection - relative filename)
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 return a DB API connection object.
database: database name
paramX: optional implementation-dependent parameters
user, password, host, port, database: all obvious, standard meaning as
in PEP-249 guidelines for connect()
For MySQLdb, the factory function would look like this:
def MySQLdb_Connection(kwargs):
from MySQLdb import connect
kwargs2 = kwargs.copy()
try:
del kwargs2['database']
kwargs2['db'] = kwargs['database']
except KeyError:
pass
try:
del kwargs2['password']
kwargs2['passwd'] = kwargs['password']
except KeyError:
pass
return connect(**kwargs2)
Of course, if you use db instead of database, and passwd instead of
password, this reduces to:
def MySQLdb_Connection(kwargs):
from MySQLdb import connect
return connect(**kwargs)
The factory functions should be fairly trivial for most database modules.
It might also be possible to (ab)use urllib2 by registering an Opener
for each database of interest which returns an DB API connection
object instead of a file-like object, and then using urllib2.urlopen()
to open connections. But it's probably better to have a seperate
module for this, i.e. dburllib.urlopen(url) -> connection. urlparse
does a good bit of the work already:
>>> import urlparse
>>> urlparse.uses_netloc.append("pydbapi-mysql")
>>> urlparse.uses_query.append("pydbapi-mysql")
>>> urlparse.urlparse('pydbapi-mysql://user:[EMAIL
>>> PROTECTED]:port/database?compress=1')
('pydbapi-mysql', 'user:[EMAIL PROTECTED]:port', '/database', '', 'compress=1',
'')
>>>
--
Computer interfaces should never be made of meat.
Using GMail? Setting Reply-to address to <> disables this annoying feature.
You are in a maze of twisty little passages all alike.
To go north, press 2. To go west, press 4.
To go east, press 6. To go south, press 8.
If you need assistance, press 0 and a little dwarf
will assist you.
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database
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 parameters
and return a DB API connection object.
database: database name
paramX: optional implementation-dependent parameters
user, password, host, port, database: all obvious, standard meaning as
in PEP-249 guidelines for connect()
The connection also should have some opportunity to parse the URI. At
least for SQLite it won't be quite the same (though it actually would
fit the pattern). How the rest gets parsed it kind of up to the driver.
I think Firebird actually uses a combination of a full path and a
hostname. Which fits fine too. Anyway, there's some diversity, though
of course I'd always prefer as much consistency as possible.
At the same time, it's important to me that I be able to parse a URI
without actually connecting to the database. So while I'd like the
database drivers to have the opportunity to do their own parsing, I'd
also like to invoke the constructor manually (or at least be able to do so).
Incidentally, I'd also like access to any extra parameters that the
parser doesn't know about, so I can use them if I wish.
I guess I'll try to code up an strawman library with this basic feel,
since there has to be a library for backward compatibility anyway.
For MySQLdb, the factory function would look like this:
def MySQLdb_Connection(kwargs):
from MySQLdb import connect
kwargs2 = kwargs.copy()
try:
del kwargs2['database']
kwargs2['db'] = kwargs['database']
except KeyError:
pass
try:
del kwargs2['password']
kwargs2['passwd'] = kwargs['password']
except KeyError:
pass
return connect(**kwargs2)
Of course, if you use db instead of database, and passwd instead of
password, this reduces to:
def MySQLdb_Connection(kwargs):
from MySQLdb import connect
return connect(**kwargs)
The factory functions should be fairly trivial for most database modules.
It might also be possible to (ab)use urllib2 by registering an Opener
for each database of interest which returns an DB API connection
object instead of a file-like object, and then using urllib2.urlopen()
to open connections. But it's probably better to have a seperate
module for this, i.e. dburllib.urlopen(url) -> connection. urlparse
does a good bit of the work already:
import urlparse
urlparse.uses_netloc.append("pydbapi-mysql")
urlparse.uses_query.append("pydbapi-mysql")
urlparse.urlparse('pydbapi-mysql://user:[EMAIL
PROTECTED]:port/database?compress=1')
('pydbapi-mysql', 'user:[EMAIL PROTECTED]:port', '/database', '', 'compress=1', '')
urllib also seems to have a lot of undocumented functions that do the
necessary parsing.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
[DB-SIG] Re: Looking for Stephen Turner, maintainer of informixdb
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 doesn't build on Python 2. I > > couldn't find any usable workarounds to the build problem, so I worked > > out successfully how to build informixdb using distutils. > > > > Now I'd like to share the result with the community, but the maintainer > > appears to have gone missing. My emails to [EMAIL PROTECTED] and > > [EMAIL PROTECTED] have bounced back undeliverable, so now I'm > > posting to the lists trying to locate Stephen. > > > > If anybody has any pointers for locating Stephen Turner, please let me > > know. If Stephen can't be located, I'd be willing to take over the > > project, but I'd prefer the torch be given to me rather than me just > > taking it. > > Carsten, > > haven't heard anything from Stephen either, but there are some extensions to > the informixdb module. I'll send the sources to you next week. So if you > like you can bundle everything in one package. Michael, I'd certainly like to take a look at those extensions. (I tried to respond to you off-list, but my mail bounced back. Is this project cursed or am I? :) I hope you're reading this, Michael.) A week has gone by with no replies as to Stephen's whereabouts, and one reply telling me that I can, in good faith, go ahead and release a fork. Unless somebody tells me I should wait longer, I guess I'll do that. Stay tuned for the announcement on when and where my fork will be available. Best regards, -- Carsten Haese - Software Engineer |Phone: (419) 861-3331 Unique Systems, Inc. | FAX: (419) 861-3340 1446 Reynolds Rd, Suite 313 | Maumee, OH 43537| mailto:[EMAIL PROTECTED] ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
Re: [DB-SIG] URI syntax for database (was: [SQLObject] Re: SQLiteconnection - relative filename)
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 become an > industry quasi-standard, is now obsoleted by ADO, the latest in a long > series of Microsoft "standards" for database access. One of the best > things about ADO, I.M.H.O., is that it does NOT use DSNs or registry > entries. > > The Python dbapi module for odbc on Windows(r) has not been maintained > for years and is acknowledged as buggy. The alternative (sorry, Mark) is > a commercial product and therefore not usable for many of us. Adodbapi > is my solution of choice. No need to be sorry - we have many happy customers :-) However, I don't really understand your comment: I was just providing the documentation for how an ODBC connection string is formatted. If you want to compare ODBC and ADO, I'd suggest to have a look at: IIS 5.0 Resource Guide: http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/reskit/iischp7.mspx Scroll down to table 7.1: """ Table 7.1 TPS (transactions per second) Per Number of Threads by MDAC Technology Threads 1 2 5 10 20 50 ODBC66.37 146.28 350.46 626.76 900.24 859.91 OLE DB 67.30 141.92 326.19 590.57 794.91 715.78 OLE DB 2.0 61.73 126.93 297.29 506.75 575.35 526.61 ADO 2.0 51.24 108.12 240.91 377.30 361.26 310.34 """ The reason for these performance figures is that ADO is an interface on top of OLE DB which in return is an interface on top of ODBC (for many database backends such as e.g. SQL Server; see figure 7.1 in the above document). This is MS at its best: stacking levels of APIs on top of each other to correct their API designs ;-) > --- > Vernon Cole > > -Original Message- > ... > >>DSNs (Data Source Names) are registry keys. The entry for that key >>contains among other things the id of the ODBC driver. The string for > > a > >>connect contains the DSN (which is evaluated by the driver manager) > > and > >>additional connect properties (which are passed to the driver). This > > at > >>least was the general idea, which has probably been bended since. > > > The format of ODBC connection strings (sometimes called DSN string > or just DSN) goes like this: > ... > (taken from > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht > m/odbcsqldriverconnect.asp; > > At the very least you have to provide the DSN= > part of the connection string. All other parts are > optional. > > ___ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 05 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
