From phd at phd.pp.ru Mon Mar 3 17:49:29 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 3 Mar 2008 19:49:29 +0300 Subject: [DB-SIG] SQLObject 0.9.4 Message-ID: <20080303164929.GD5252@phd.pp.ru> Hello! I'm pleased to announce the 0.9.4 release of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.9.4 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.9.3 ---------------- Bug Fixes ~~~~~~~~~ * Use list.reverse() in manager/command.py for Python 2.2 compatibility. * Prevent MultipleJoin from removing the intermediate table if it was not created by the Join. * Fixed a bug with no default when defaultSQL is defined for the column. * Recognize POINT data type as string in PostgresConnection.columnsFromSchema(). For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From mal at egenix.com Mon Mar 3 19:46:53 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 03 Mar 2008 19:46:53 +0100 Subject: [DB-SIG] two phase commit API (again) In-Reply-To: <47C541E1.6040301@egenix.com> References: <47C541E1.6040301@egenix.com> Message-ID: <47CC479D.2000701@egenix.com> On 2008-02-27 11:56, M.-A. Lemburg wrote: > On 2008-02-27 05:00, James Henstridge wrote: >> I dropped the ball a bit on this. >> >> I took the last round of feedback and integrated it into a new version >> of the specification. If people are happy with this, what is the next >> step? > > Looks good. > > If there are no further issues to discuss, then I'll add it to the > DB-API spec as standard extension. I've edited the text a bit and added it to PEP 249. The website should pick this up after a while. Thanks for keeping the ball rolling on this API extension. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 2008) >>> 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,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Mon Mar 3 13:40:24 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 03 Mar 2008 13:40:24 +0100 Subject: [DB-SIG] two phase commit API (again) In-Reply-To: <47C541E1.6040301@egenix.com> References: <47C541E1.6040301@egenix.com> Message-ID: <47CBF1B8.9030503@egenix.com> On 2008-02-27 11:56, M.-A. Lemburg wrote: > On 2008-02-27 05:00, James Henstridge wrote: >> I dropped the ball a bit on this. >> >> I took the last round of feedback and integrated it into a new version >> of the specification. If people are happy with this, what is the next >> step? > > Looks good. > > If there are no further issues to discuss, then I'll add it to the > DB-API spec as standard extension. I've edited the text a bit and added it to PEP 249. The website should pick this up after a while. Thanks for keeping the ball rolling on this API extension. I've attached the new version of the DB-API 2.0 below. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 2008) >>> 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,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pep-0249.txt Url: http://mail.python.org/pipermail/db-sig/attachments/20080303/eef9c326/attachment-0001.txt From phd at phd.pp.ru Mon Mar 10 12:38:16 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Mon, 10 Mar 2008 14:38:16 +0300 Subject: [DB-SIG] SQLObject 0.9.5 Message-ID: <20080310113816.GC14369@phd.pp.ru> Hello! I'm pleased to announce the 0.9.5, a minor bug fix release of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.9.5 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.9.4 ---------------- Bug Fixes ~~~~~~~~~ * Fixed a minor bug in SQLiteConnection.columnsFromSchema() - set dbName. * A bug in delColumn() that removes all properties is fixed by recreating properties. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From phd at phd.pp.ru Tue Mar 11 14:40:31 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Tue, 11 Mar 2008 16:40:31 +0300 Subject: [DB-SIG] SQLObject 0.10.0 Message-ID: <20080311134031.GC14147@phd.pp.ru> Hello! I'm pleased to announce version 0.10.0, the first stable release of 0.10 branch of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.10.0 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.9 -------------- Features & Interface ~~~~~~~~~~~~~~~~~~~~ * Dropped support for Python 2.2. The minimal version of Python for SQLObject is 2.3 now. * Removed actively deprecated attributes; lowered deprecation level for other attributes to be removed after 0.10. * SQLBuilder Select supports the rest of SelectResults options (reversed, distinct, joins, etc.) * SQLObject.select() (i.e., SelectResults) and DBConnection.queryForSelect() use SQLBuilder Select queries; this make all SELECTs implemented internally via a single mechanism. * SQLBuilder Joins handle SQLExpression tables (not just str/SQLObject/Alias) and properly sqlrepr. * Added SQLBuilder ImportProxy. It allows one to ignore the circular import issues with referring to SQLObject classes in other files - it uses the classregistry as the string class names for FK/Joins do, but specifically intended for SQLBuilder expressions. See tests/test_sqlbuilder_importproxy.py. * Added SelectResults.throughTo. It allows one to traverse relationships (FK/Join) via SQL, avoiding the intermediate objects. Additionally, it's a simple mechanism for pre-caching/eager-loading of later FK relationships (i.e., going to loop over a select of somePeople and ask for aPerson.group, first call list(somePeople.throughTo.group) to preload those related groups and use 2 db queries instead of N+1). See tests/test_select_through.py. * Added ViewSQLObject. * Added sqlmeta.getColumns() to get all the columns for a class (including parent classes), excluding the column 'childName' and including the column 'id'. sqlmeta.asDict() now uses getColumns(), so there is no need to override it in the inheritable sqlmeta class; this makes asDict() to work properly on inheritable sqlobjects. * Allow MyTable.select(MyTable.q.foreignKey == object) where object is an instance of SQLObject. * Added rich comparison methods; SQLObjects of the same class are considered equal is they have the same id; other methods return NotImplemented. * RowDestroySignal is sent on destroying an SQLObject instance; postfunctions are run after the row has been destroyed. * Changed the implementation type in BoolCol under SQLite from TINYINT to BOOLEAN and made fromDatabase machinery to recognize it. * MySQLConnection (and DB URI) accept a number of SSL-related parameters: ssl_key, ssl_cert, ssl_ca, ssl_capath. * Use sets instead of dicts in tablesUsed. Dropped tablesUsedDict function; instead there is tablesUsedSet that returns a set of strings. * SQLBuilder tablesUsedSet handles sqlrepr'able objects. * Under MySQL, PickleCol no longer uses TEXT column types; the smallest column is now BLOB - it is not possible to create TINYBLOB column. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From robert.rawlins at thinkbluemedia.co.uk Wed Mar 12 16:02:43 2008 From: robert.rawlins at thinkbluemedia.co.uk (Robert Rawlins) Date: Wed, 12 Mar 2008 15:02:43 -0000 Subject: [DB-SIG] Is this the right place? Message-ID: <007301c88452$2002ac90$600805b0$@rawlins@thinkbluemedia.co.uk> Morning guys, I'm looking for a users mailing list for the DB-API to ask a few questions about how it is best implemented into my application, is this the best place to send these sorts of questions too or do you have a users mailing list? Thanks guys, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20080312/048fd5fc/attachment.htm From andy47 at halfcooked.com Wed Mar 12 21:20:54 2008 From: andy47 at halfcooked.com (Andy Todd) Date: Thu, 13 Mar 2008 07:20:54 +1100 Subject: [DB-SIG] Is this the right place? In-Reply-To: <007301c88452$2002ac90$600805b0$@rawlins@thinkbluemedia.co.uk> References: <007301c88452$2002ac90$600805b0$@rawlins@thinkbluemedia.co.uk> Message-ID: <47D83B26.6080107@halfcooked.com> Robert Rawlins wrote: > Morning guys, > > > > I?m looking for a users mailing list for the DB-API to ask a few > questions about how it is best implemented into my application, is this > the best place to send these sorts of questions too or do you have a > users mailing list? > > > > Thanks guys, > > > > Robert > Robert, This is the place to discuss all things DB-API. Fire away. Regards, Andy -- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From robert.rawlins at tamedtechnology.co.uk Thu Mar 13 10:04:17 2008 From: robert.rawlins at tamedtechnology.co.uk (Robert Rawlins - Tamed Technology) Date: Thu, 13 Mar 2008 09:04:17 -0000 Subject: [DB-SIG] Managing My Database Connections Message-ID: <006e01c884e9$38f29ed0$aad7dc70$@rawlins@tamedtechnology.co.uk> Hello Guys, Well, thanks to Andy Todd I now know this to be the correct list to post on so thought I would start a new thread with my question. Essentially I only have a single database attached to my application but I'm looking for the best way to handle its connection so thought I would come and get your thoughts and opinions. Within my applications I'll have many classes which access the database, I'm wondering to what level I should extract the database connection. Should I create a new database connection and close it for every method which calls the database? Should I create the connection to the DB when I construct the class and place the cursor in the self scope? Or should I create an application wide connection to the database and inject the connection into all the classes which require it? At the moment I've created a singleton class which contains the connection to the database, I then pass this class into my other objects and store it as a property in the self scope. Then, for each function which needs to access the database I create a new cursor and then close the cursor at the end of the method, like so: class someclass: # I'm the constructor method def __init__(self, connection): # Create the connection self.connection = connection # Method which calls the database def mymethod(self): new_cursor = self.connection.cursor() new_cursor.execute("""INSERT INTO......""") new_cursor.close() Is this the best way to handle things? I'm simply looking for the least verbose and simple way to query the database. Thanks for your advice and thoughts, I look forward to seeing how you guys handle this. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20080313/4bc31133/attachment.htm From gh at ghaering.de Thu Mar 13 17:00:17 2008 From: gh at ghaering.de (=?windows-1252?Q?Gerhard_H=E4ring?=) Date: Thu, 13 Mar 2008 17:00:17 +0100 Subject: [DB-SIG] Managing My Database Connections In-Reply-To: <006e01c884e9$38f29ed0$aad7dc70$@rawlins@tamedtechnology.co.uk> References: <006e01c884e9$38f29ed0$aad7dc70$@rawlins@tamedtechnology.co.uk> Message-ID: <47D94F91.7070408@ghaering.de> Robert Rawlins - Tamed Technology wrote: > Essentially I only have a single database attached to my application but > I?m looking for the best way to handle its connection so thought I would > come and get your thoughts and opinions. > > Within my applications I?ll have many classes which access the database, > I?m wondering to what level I should extract the database connection. [...] Be sure to wrap the actual "getting the connection object". > Should I create a new database connection and close it for every method > which calls the database? Should I create the connection to the DB when > I construct the class and place the cursor in the self scope? Or should > I create an application wide connection to the database and inject the > connection into all the classes which require it? [...] That's what I'd do. But I'd not inject it and rather just get it (like with get_con() in my example code). I've attached example code that shows how DB-API database access can be simplified. -- Gerhard -------------- next part -------------- A non-text attachment was scrubbed... Name: db_example.py Type: text/x-python Size: 2266 bytes Desc: not available Url : http://mail.python.org/pipermail/db-sig/attachments/20080313/62bc6415/attachment.py From brunson at brunson.com Mon Mar 17 19:30:22 2008 From: brunson at brunson.com (Eric Brunson) Date: Mon, 17 Mar 2008 12:30:22 -0600 Subject: [DB-SIG] Parameter substitution and "IN" operator Message-ID: <47DEB8BE.9030905@brunson.com> Has there been any discussion of supporting lists or tuples as parameters to the "IN" operator? I'd like to be able to do something to the effect of: curs.execute( "select * from mytable where col1 = %s and col2 in (%s)", ( 'firstval', ('list', 'of', 'vals') ) Or perhaps: curs.execute( "select * from mytable where col1 = %s and col2 in %s", ( 'firstval', ('list', 'of', 'vals') ) And have the module include the parens. It seems to almost work sometimes: c.execute( 'select * from gateway where code in %s', ( ( 1, 2 ), ) ) print c._executed Yields: select * from gateway where code in ('1', '2') but c.execute( 'select * from gateway where code in %s', ( ( 'cys', 'syr' ), ) ) print c._executed yields: select * from gateway where code in ("'cys'", "'syr'") Besides, I think it's just a side effect of the string representations of the tuple and not a planned feature. I know how to build a string with the correct number of placeholders for my "IN" list, but I think it would be a nice feature of the API to handle it for the the user. Thanks, e. From gh at ghaering.de Tue Mar 18 00:14:39 2008 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Tue, 18 Mar 2008 00:14:39 +0100 Subject: [DB-SIG] Parameter substitution and "IN" operator In-Reply-To: <47DEB8BE.9030905@brunson.com> References: <47DEB8BE.9030905@brunson.com> Message-ID: <47DEFB5F.5050801@ghaering.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Brunson wrote: > Has there been any discussion of supporting lists or tuples as > parameters to the "IN" operator? [...] I didn't search the archives, either ;-) > I'd like to be able to do something to the effect of: > > curs.execute( "select * from mytable where col1 = %s and col2 in (%s)", > ( 'firstval', ('list', 'of', 'vals') ) > > > Or perhaps: > > curs.execute( "select * from mytable where col1 = %s and col2 in %s", > ( 'firstval', ('list', 'of', 'vals') ) > > > And have the module include the parens. [...] This is not the way SQL parameter binding works. SQL parameter binding only works with scalars (*). If tuples seem to work, then that's just a side-effect of the implementation of your particular DB-API module. Certain DB-API modules like pyPgSQL (and IIRC psycopg and MySQLdb) try to make your requested feature work. That's only possible because the database involved (MySQL and PostgreSQL, at least older versions) didn't really support parameter binding. And if the database doesn't support it, it is then "faked" on the Python side using escaping values and string substitution. If the database, however, supports parameter binding natively, like most major ones do, and even small ones like SQLite, then your feature request cannot be implemented. HTH, - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3vtfdIO4ozGCH14RApQrAKDBZ+dm6rO0nYkDfiLD4hpwKipycwCfR/l7 pUUMxm//EkvHUrEHAokO65c= =YOe1 -----END PGP SIGNATURE----- From alex at moreati.org.uk Tue Mar 18 00:35:03 2008 From: alex at moreati.org.uk (Alex Willmer) Date: Mon, 17 Mar 2008 23:35:03 +0000 Subject: [DB-SIG] Parameter substitution and "IN" operator In-Reply-To: <47DEFB5F.5050801@ghaering.de> References: <47DEB8BE.9030905@brunson.com> <47DEFB5F.5050801@ghaering.de> Message-ID: <1205796903.6294.3.camel@martha> On Tue, 2008-03-18 at 00:14 +0100, Gerhard H?ring wrote: > This is not the way SQL parameter binding works. SQL parameter binding > only works with scalars (*). If tuples seem to work, then that's just > a side-effect of the implementation of your particular DB-API module. >>From here, it seems like native SQL parameter binding for tuples is a good thing. Do relational databases not implement it merely because no one has written the code yet, or is it missing from the SQL standard/a bad idea in principle? Regards, Alex From gh at ghaering.de Tue Mar 18 01:18:59 2008 From: gh at ghaering.de (=?UTF-8?B?R2VyaGFyZCBIw6RyaW5n?=) Date: Tue, 18 Mar 2008 01:18:59 +0100 Subject: [DB-SIG] Parameter substitution and "IN" operator In-Reply-To: <1205796903.6294.3.camel@martha> References: <47DEB8BE.9030905@brunson.com> <47DEFB5F.5050801@ghaering.de> <1205796903.6294.3.camel@martha> Message-ID: <47DF0A73.6050205@ghaering.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Willmer wrote: > On Tue, 2008-03-18 at 00:14 +0100, Gerhard H?ring wrote: >> This is not the way SQL parameter binding works. SQL parameter binding >> only works with scalars (*). If tuples seem to work, then that's just >> a side-effect of the implementation of your particular DB-API module. > >> >From here, it seems like native SQL parameter binding for tuples is a > good thing. Do relational databases not implement it merely because no > one has written the code yet, or is it missing from the SQL standard/a > bad idea in principle? It's missing from the SQL standard. And it's not implemented because it would make the main idea of parameter binding useless: reusing query plans. I agree that in theory the "SQL-to-virtual-machine compiler" on the database backends could be smarter like this, but it would probably add too much complexity. If you really really need the functionality with "IN" and want native parameter binding, you can fake it using temporary tables. Pseudo-code: select ... from table1 where col1 in (select col2 from tmp_table). or select ... from table1 where exists (select 1 from tmp_table where col2=table1.col1) The EXISTS version is better with some databases (certainly it was for Oracle 8, which just "cut off" values in "IN" clauses if you had more than 255 or something). - -- Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3wpzdIO4ozGCH14RAmPuAJ9QNEgiBU4pcKqTc+k3/MBTe5pFBgCfS5oA VRizXimLdIj6hExBIvaOObI= =Cj32 -----END PGP SIGNATURE----- From andy47 at halfcooked.com Wed Mar 19 10:08:31 2008 From: andy47 at halfcooked.com (Andy Todd) Date: Wed, 19 Mar 2008 20:08:31 +1100 Subject: [DB-SIG] Managing My Database Connections In-Reply-To: <47D94F91.7070408@ghaering.de> References: <006e01c884e9$38f29ed0$aad7dc70$@rawlins@tamedtechnology.co.uk> <47D94F91.7070408@ghaering.de> Message-ID: <47E0D80F.9010709@halfcooked.com> Gerhard H?ring wrote: > Robert Rawlins - Tamed Technology wrote: >> Essentially I only have a single database attached to my application >> but I?m looking for the best way to handle its connection so thought I >> would come and get your thoughts and opinions. >> Within my applications I?ll have many classes which access the >> database, I?m wondering to what level I should extract the database >> connection. [...] > > Be sure to wrap the actual "getting the connection object". > >> Should I create a new database connection and close it for every >> method which calls the database? Should I create the connection to >> the DB when I construct the class and place the cursor in the self >> scope? Or should I create an application wide connection to the >> database and inject the connection into all the classes which require >> it? [...] > > That's what I'd do. But I'd not inject it and rather just get it (like > with get_con() in my example code). > > I've attached example code that shows how DB-API database access can be > simplified. > > -- Gerhard > Nice. I have a module that abstracts getting the initial connection and attempts a standard URI scheme; http://halfcooked.com/blog/2006/09/20/python-25-and-generic-database-connection-utilities/ Somewhere in the combination is a 'simplified' DB-API fighting to get out ... Regards, Andy -- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From gh at ghaering.de Wed Mar 19 13:23:26 2008 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Wed, 19 Mar 2008 13:23:26 +0100 Subject: [DB-SIG] Proposed DB-API extensions Message-ID: <47E105BE.5080608@ghaering.de> I'd like to propose the attached changes to the DB-API spec. My main motivation is to make DB-API modules less cumbersome to use when used directly. If you want to try it out live, everything except .fetchscalar() is already implemented in pysqlite. The __enter__/__exit__ thing is in pysqlite and cx_Oracle. ==> .execute(), .executemany() returning self. Ability to write shorter code. No more: cur.execute("select ...") for row in cur: ... instead: for row in cur.exeucte("..."): ... ==> .execute(), .executemany() in connection object. They should have been placed here anyway. *cough* Users shouldn't have to mess with cursor objects normally. Ability to write shorter code: con = module.connect(...) for row in con.execute("..."): ... ==> __enter__ and __exit__ in the connection object. Ability to automatically wrap database code in transactions, when using Python 2.5 or higher: with con: con.execute(DML1) con.execute(DML2) no more: try: cur = con.cursor() cur.execute(DML1) cur.execute(DML2) con.commit() except: con.rollback() ==> fetchscalar method in cursor object This one is low-prio for me, but it's a common use case to only query a scalar value. -- Gerhard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: db_api_extensions.diff Url: http://mail.python.org/pipermail/db-sig/attachments/20080319/181689dc/attachment.txt From carsten at uniqsys.com Wed Mar 19 14:25:08 2008 From: carsten at uniqsys.com (Carsten Haese) Date: Wed, 19 Mar 2008 14:25:08 +0100 Subject: [DB-SIG] Proposed DB-API extensions In-Reply-To: <47E105BE.5080608@ghaering.de> References: <47E105BE.5080608@ghaering.de> Message-ID: <1205933108.3369.30.camel@localhost.localdomain> On Wed, 2008-03-19 at 13:23 +0100, Gerhard H?ring wrote: > ==> .execute(), .executemany() returning self. +1. I agree that this is nice to have. > ==> .execute(), .executemany() in connection object. -0. Most queries get executed more than once. Not explicitly creating a cursor to cache the statement negates the advantage of statement caching, or it would make statement caching harder to implement. This feature adds convenience for executing one-of queries, but I'm worried people might use it in circumstances where creating a dedicated cursor object would result in better performance. > ==> __enter__ and __exit__ in the connection object...to automatically wrap database code in transactions -1. InformixDB uses connection.__exit__ to close the connection, whereas cx_Oracle uses connection.__exit__ to commit/rollback a transaction, so the train for standardizing this has left the station already. Also, I think explicitly committing or rolling back is a Good Thing in my opinion. I would however not be opposed to making a new connection method that would return a "transaction context" object with the proposed behavior. (For sqlite and cx_Oracle, this would merely be a shim that returns self.) That way, the fact that a transaction is being managed is explicitly visible, and we avoid the pre-existing incompatible use cases for connection.__exit__ . > ==> fetchscalar method in cursor object +0. I have no problem with implementing this, but I don't see much use for it myself. Best regards, -- Carsten Haese http://informixdb.sourceforge.net From anthony.tuininga at gmail.com Wed Mar 19 15:04:17 2008 From: anthony.tuininga at gmail.com (Anthony Tuininga) Date: Wed, 19 Mar 2008 08:04:17 -0600 Subject: [DB-SIG] Proposed DB-API extensions In-Reply-To: <1205933108.3369.30.camel@localhost.localdomain> References: <47E105BE.5080608@ghaering.de> <1205933108.3369.30.camel@localhost.localdomain> Message-ID: <703ae56b0803190704t37a80752peb6d6fe453a09e31@mail.gmail.com> On Wed, Mar 19, 2008 at 7:25 AM, Carsten Haese wrote: > On Wed, 2008-03-19 at 13:23 +0100, Gerhard H?ring wrote: > > ==> .execute(), .executemany() returning self. > > +1. I agree that this is nice to have. +1. I agree with this as well. I did not implement this in cx_Oracle but I did in ceODBC after seeing it used to great advantage in another driver -- I forget which one, though. :-) I'll be looking at putting this into cx_Oracle as well. > > ==> .execute(), .executemany() in connection object. > > -0. Most queries get executed more than once. Not explicitly creating a > cursor to cache the statement negates the advantage of statement > caching, or it would make statement caching harder to implement. > > This feature adds convenience for executing one-of queries, but I'm > worried people might use it in circumstances where creating a dedicated > cursor object would result in better performance. I don't see much advantage here either but if the first enhancement is included then it becomes very simple to implement anyway and it could be nice syntax sugar. :-) > > ==> __enter__ and __exit__ in the connection object...to automatically wrap database code in transactions > > -1. InformixDB uses connection.__exit__ to close the connection, whereas > cx_Oracle uses connection.__exit__ to commit/rollback a transaction, so > the train for standardizing this has left the station already. Also, I > think explicitly committing or rolling back is a Good Thing in my > opinion. +1 from me but that would be obvious considering that cx_Oracle already implements this. :-) Having __enter__ and __exit__ used for closing a connection seems pointless since you can just as easily use: with contextlib.closing(connection): # do something Having to do this: try: # do something connection.commit() except: connection.rollback() raise seems to me to be precisely what context was about in the first place! And generally a connection is used frequently so using __exit__ for closing a connection would be very infrequently used at best. with connection: # do something is far cleaner, in my opinion. > I would however not be opposed to making a new connection method that > would return a "transaction context" object with the proposed behavior. > (For sqlite and cx_Oracle, this would merely be a shim that returns > self.) That way, the fact that a transaction is being managed is > explicitly visible, and we avoid the pre-existing incompatible use cases > for connection.__exit__ . It seems to me to be extra work for little advantage but if everyone else disagrees with me I have no particular issue with this suggestion. > > ==> fetchscalar method in cursor object > > +0. I have no problem with implementing this, but I don't see much use > for it myself. Agreed. I haven't felt the need for this myself. > Best regards, > > -- > Carsten Haese > http://informixdb.sourceforge.net > > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig > From anthonybaxter at gmail.com Thu Mar 20 02:04:02 2008 From: anthonybaxter at gmail.com (Anthony Baxter) Date: Thu, 20 Mar 2008 12:04:02 +1100 Subject: [DB-SIG] Proposed DB-API extensions In-Reply-To: <47E105BE.5080608@ghaering.de> References: <47E105BE.5080608@ghaering.de> Message-ID: 2008/3/19 Gerhard H?ring : > I'd like to propose the attached changes to the DB-API spec. My main > motivation is to make DB-API modules less cumbersome to use when used > directly. > ==> .execute(), .executemany() returning self. +1 > ==> .execute(), .executemany() in connection object. > > They should have been placed here anyway. *cough* Users shouldn't have > to mess with cursor objects normally. Ability to write shorter code: strong -1 from me. the lazy user can write for row in conn.cursor().execute(...) if they really don't care. > ==> __enter__ and __exit__ in the connection object. > > Ability to automatically wrap database code in transactions, when using > Python 2.5 or higher: Seems useful. +1. > ==> fetchscalar method in cursor object > > This one is low-prio for me, but it's a common use case to only query a > scalar value. I'm not convinced that fetchscalar() is the best name for this method. It's meaning isn't immediately obvious. But I may just be dense :-) Anthony From mal at egenix.com Thu Mar 20 14:35:36 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 20 Mar 2008 14:35:36 +0100 Subject: [DB-SIG] Proposed DB-API extensions In-Reply-To: <47E105BE.5080608@ghaering.de> References: <47E105BE.5080608@ghaering.de> Message-ID: <47E26828.5040208@egenix.com> On 2008-03-19 13:23, Gerhard H?ring wrote: > I'd like to propose the attached changes to the DB-API spec. My main > motivation is to make DB-API modules less cumbersome to use when used > directly. > > If you want to try it out live, everything except .fetchscalar() is > already implemented in pysqlite. The __enter__/__exit__ thing is in > pysqlite and cx_Oracle. > > > ==> .execute(), .executemany() returning self. > > Ability to write shorter code. No more: > > cur.execute("select ...") > for row in cur: > ... > > instead: > > for row in cur.exeucte("..."): > ... Nice to have, yes, but I'm -1 on putting that into the standard: it doesn't work well with implementations that already return a result set object for .execute*(). Remember that the return value for .execute*() was left undefined in DB-API 2.0 to make this possible. In DB-API 1.0, .execute*() used to return the cursor.rowcount. > ==> .execute(), .executemany() in connection object. > > They should have been placed here anyway. *cough* Users shouldn't have > to mess with cursor objects normally. Ability to write shorter code: > > con = module.connect(...) > for row in con.execute("..."): > ... -1. We explicitly removed this option in the transition from DB-API 1.0 to 2.0, so adding it back again is not a good idea. > ==> __enter__ and __exit__ in the connection object. > > Ability to automatically wrap database code in transactions, when using > Python 2.5 or higher: > > with con: > con.execute(DML1) > con.execute(DML2) > > no more: > > try: > cur = con.cursor() > cur.execute(DML1) > cur.execute(DML2) > con.commit() > except: > con.rollback() -1 on putting that definition in the standard. con.execute() is a no-no (see above). Even if you do implement things that way, the "with" statement would not be thread-safe. IMHO, it's much better to write a context manager that takes care of whatever logic is needed for your application and then use: with context.transactional(con): cur = con.cursor() cur.execute(DML1) cur.execute(DML2) > ==> fetchscalar method in cursor object > > This one is low-prio for me, but it's a common use case to only query a > scalar value. -1 on adding that method to the standard. While it's true that many queries just need the first row and the first value from that query, the error handling will get more complicated due to some databases returning an empty result set instead of a single row return value e.g. when using "SELECT COUNT(*) ..." Note that all the -1s are just for adjusting the DB-API standard. You are still free to implement these things in your modules. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 20 2008) >>> 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,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611