From ianb at colorstudy.com Sat Nov 1 16:29:46 2003 From: ianb at colorstudy.com (Ian Bicking) Date: Sat Nov 1 16:29:52 2003 Subject: [DB-SIG] ANN: SQLObject 0.5 Message-ID: <83DCFF80-0CB2-11D8-92EF-000393C2D67E@colorstudy.com> SQLObject 0.5 ============= SQLObject is an Object-Relational Mapper (ORM), wrapping your database tables in easy-to-use Python classes. Changes ------- * Firebird support. * Generic conversion routines (makes a BoolCol possible). * Non-integer primary keys. * Instance (row) caches can be synced or expired relative to the database. * Many transaction-related bugs fixed. * And smaller stuff too. Where: Home: http://sqlobject.org Changes: http://sqlobject.org/docs/News.html Docs: http://sqlobject.org/docs/SQLObject.html Download: http://prdownloads.sf.net/sqlobject/SQLObject-0.5.tar.gz?download -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org From bgudorf at neurokode.com Mon Nov 3 11:06:12 2003 From: bgudorf at neurokode.com (Bryan J Gudorf) Date: Mon Nov 3 11:06:21 2003 Subject: [DB-SIG] Python Database Objects (PDO) 1.1.0 Released Message-ID: Hey Everyone, We have released a new version of Python Database Objects. This fairly stable test release adds support for various databases through the mxODBC module. In this release we have added several pieces of functionality, such as move() and moveto() which allow you to move dynamically through a recordset at your will. As we move forward in the 1.1 series we will be adding support for more databases. Community support and feedback is appreciated so that we can make PDO as useful as possible. Bryan J Gudorf. ~NeuroKode Labs From guido at python.org Fri Nov 14 19:39:34 2003 From: guido at python.org (Guido van Rossum) Date: Fri Nov 14 19:39:42 2003 Subject: [DB-SIG] Which Oracle extension to use? Message-ID: <200311150039.hAF0dY705542@12-236-54-216.client.attbi.com> We're about to start developing for Oracle 9 (or is that 9i???) on Linux. I know that there are several Oracle extensions for Python, but I've never used either of them. If you have relevant experience, please let me know (private mail will be fine). --Guido van Rossum (home page: http://www.python.org/~guido/) From andy47 at halfcooked.com Sat Nov 15 11:08:33 2003 From: andy47 at halfcooked.com (Andy Todd) Date: Sat Nov 15 11:11:33 2003 Subject: [DB-SIG] Which Oracle extension to use? In-Reply-To: <200311150039.hAF0dY705542@12-236-54-216.client.attbi.com> References: <200311150039.hAF0dY705542@12-236-54-216.client.attbi.com> Message-ID: <3FB64F81.7050405@halfcooked.com> Guido van Rossum wrote: > We're about to start developing for Oracle 9 (or is that 9i???) on > Linux. I know that there are several Oracle extensions for Python, > but I've never used either of them. If you have relevant experience, > please let me know (private mail will be fine). > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig Guido, There are two that I know of and have used successfully; cx_Oracle : http://www.computronix.com/utilities.shtml#Oracle DCOracle2 : http://www.zope.org/Members/matt/dco2 cx_Oracle is more actively maintained (and there are a number of other Oracle utilities on that page) but both work well. It's 9i by the way. Unless you've managed to get an early copy of 10g ;-) Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From bgudorf at neurokode.com Mon Nov 17 01:55:48 2003 From: bgudorf at neurokode.com (Bryan J Gudorf) Date: Mon Nov 17 01:55:56 2003 Subject: [DB-SIG] Python Database Objects (PDO) 1.2.0 Released Message-ID: PDO, an open source python module for interfacing with RDBMS (SQL databases), has now reached 1.2.0! PDO provides an object oriented API, similar to that of ADO or JDBC, to python developers. PDO features column access by name. This new release adds support for the cx_Oracle, DB2 and adodbapi modules, allowing users to use PDO with a variety of database systems. 9 different DBAPI modules are now supported, allowing for PDO to be used with almost any RDBMS. Additional features, such as query parameters, have also been added in this release, as well as the usual bug-fixes. PDO is released under a BSD style license. PDO supports the following DBAPI python modules and databases: MySQLdb (supports MySQL) PySQLite (SQLite) pgdb (PostgreSQL) kinterbasdb (Firebird, Interbase) mxODBC (Many) pyDB2 (IBM's DB/2) cx_Oracle (Oracle) adodbapi (windows only - any RDBMS with an OLE DB provider or ODBC driver) As we move forward in this series we will be adding further functionality and support. Community support and feedback is appreciated so that we can make PDO as useful as possible. Downloads for Python Database Objects are available on SourceForge.Net or for more information please visit pdo.neurokode.com. Bryan J Gudorf ~NeuroKode Labs From gh at ghaering.de Mon Nov 17 10:44:25 2003 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Mon Nov 17 10:44:32 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True Message-ID: <3FB8ECD9.5080708@ghaering.de> Several database modules seem to have a sort of unofficial extension - the autocommit mode, without transaction handling. I'd like to hear your opinion on what .commit()/.rollback() should do in this case. Option 1) Behaviour: .commit() dies nothing, .rollback() raises an exception Rationale: this makes it easier to program applications that work in both autocommit mode and transactional mode, depending on the configuration or DB-API module used. Option 2) Behaviour: .commit() and .rollback() both raise an exception Rationale: There is nothing to commit or roll back, so these calls don't make any sense and the user should be alerted of this fact. Option 3) Behaviour: .commit() and .rollback() both do nothing. Rationale: (Almost) same as #1? Do you have any other suggestions? Which would you prefer? -- Gerhard From TKeating at origin.ea.com Mon Nov 17 10:47:17 2003 From: TKeating at origin.ea.com (Keating, Tim) Date: Mon Nov 17 10:47:26 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True Message-ID: <25BCE2B1149CDA4E9758CC08E70A20A9038C857F@eahq-mb1> These should do exactly what they do now when called on a session that has nothing to commit or rollback. -----Original Message----- From: db-sig-bounces@python.org [mailto:db-sig-bounces@python.org] On Behalf Of Gerhard H?ring Sent: Monday, November 17, 2003 9:44 AM To: db-sig@python.org Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True Several database modules seem to have a sort of unofficial extension - the autocommit mode, without transaction handling. I'd like to hear your opinion on what .commit()/.rollback() should do in this case. Option 1) Behaviour: .commit() dies nothing, .rollback() raises an exception Rationale: this makes it easier to program applications that work in both autocommit mode and transactional mode, depending on the configuration or DB-API module used. Option 2) Behaviour: .commit() and .rollback() both raise an exception Rationale: There is nothing to commit or roll back, so these calls don't make any sense and the user should be alerted of this fact. Option 3) Behaviour: .commit() and .rollback() both do nothing. Rationale: (Almost) same as #1? Do you have any other suggestions? Which would you prefer? -- Gerhard _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From mal at lemburg.com Mon Nov 17 11:37:16 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Nov 17 11:37:09 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True In-Reply-To: <3FB8ECD9.5080708@ghaering.de> References: <3FB8ECD9.5080708@ghaering.de> Message-ID: <3FB8F93C.1040809@lemburg.com> Gerhard H?ring wrote: > Several database modules seem to have a sort of unofficial extension - > the autocommit mode, without transaction handling. I'd like to hear your > opinion on what .commit()/.rollback() should do in this case. The DB API 2.0 defines this case to be implemented according to your option 1. > Option 1) > > Behaviour: .commit() dies nothing, .rollback() raises an exception > > Rationale: this makes it easier to program applications that work in > both autocommit mode and transactional mode, depending on the > configuration or DB-API module used. > > > Option 2) > > Behaviour: .commit() and .rollback() both raise an exception > Rationale: There is nothing to commit or roll back, so these calls don't > make any sense and the user should be alerted of this fact. > > > Option 3) > > Behaviour: .commit() and .rollback() both do nothing. > > Rationale: (Almost) same as #1? > > > Do you have any other suggestions? Which would you prefer? > > -- Gerhard > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... 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 ! :::: From ods at strana.ru Mon Nov 17 11:39:11 2003 From: ods at strana.ru (Denis S. Otkidach) Date: Mon Nov 17 12:02:19 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True In-Reply-To: <3FB8ECD9.5080708@ghaering.de> Message-ID: Only 1) and 2) are acceptable. Rollback MUST raise exception if it ever called since transaction can't be rolled back. On Mon, 17 Nov 2003, [ISO-8859-1] Gerhard H?ring wrote: GH> Several database modules seem to have a sort of unofficial GH> extension - GH> the autocommit mode, without transaction handling. I'd like GH> to hear your GH> opinion on what .commit()/.rollback() should do in this GH> case. GH> GH> Option 1) GH> GH> Behaviour: .commit() dies nothing, .rollback() raises an GH> exception GH> GH> Rationale: this makes it easier to program applications that GH> work in GH> both autocommit mode and transactional mode, depending on GH> the GH> configuration or DB-API module used. GH> GH> GH> Option 2) GH> GH> Behaviour: .commit() and .rollback() both raise an exception GH> Rationale: There is nothing to commit or roll back, so these GH> calls don't GH> make any sense and the user should be alerted of this fact. GH> GH> GH> Option 3) GH> GH> Behaviour: .commit() and .rollback() both do nothing. GH> GH> Rationale: (Almost) same as #1? GH> GH> GH> Do you have any other suggestions? Which would you prefer? -- Denis S. Otkidach http://www.python.ru/ [ru] From Martin.Moellenbeck at t-online.de Tue Nov 18 13:04:23 2003 From: Martin.Moellenbeck at t-online.de (=?ISO-8859-1?Q?Martin_M=F6llenbeck?=) Date: Tue Nov 18 13:04:52 2003 Subject: [DB-SIG] Which Oracle extension to use? In-Reply-To: <3FB64F81.7050405@halfcooked.com> References: <200311150039.hAF0dY705542@12-236-54-216.client.attbi.com> <3FB64F81.7050405@halfcooked.com> Message-ID: <3FBA5F27.7070608@t-online.de> sorry, must go to the list Andy Todd wrote: > Guido van Rossum wrote: > >> We're about to start developing for Oracle 9 (or is that 9i???) on >> Linux. I know that there are several Oracle extensions for Python, >> but I've never used either of them. If you have relevant experience, >> please let me know (private mail will be fine). >> >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> >> _______________________________________________ >> DB-SIG maillist - DB-SIG@python.org >> http://mail.python.org/mailman/listinfo/db-sig > > > Guido, > > There are two that I know of and have used successfully; > > cx_Oracle : http://www.computronix.com/utilities.shtml#Oracle > DCOracle2 : http://www.zope.org/Members/matt/dco2 > > cx_Oracle is more actively maintained (and there are a number of other > Oracle utilities on that page) but both work well. > > It's 9i by the way. Unless you've managed to get an early copy of 10g ;-) > > Regards, > Andy but when threadsafety is important, have a closer look to the docs of the modules. Regards, Martin From anthony at computronix.com Tue Nov 18 14:18:33 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Tue Nov 18 14:18:45 2003 Subject: [DB-SIG] Which Oracle extension to use? In-Reply-To: <3FBA5F27.7070608@t-online.de> References: <200311150039.hAF0dY705542@12-236-54-216.client.attbi.com> <3FB64F81.7050405@halfcooked.com> <3FBA5F27.7070608@t-online.de> Message-ID: <1069183113.25790.42.camel@chl0122.edmonton.computronix.com> On Tue, 2003-11-18 at 11:04, Martin M?llenbeck wrote: > sorry, must go to the list > > Andy Todd wrote: > > > Guido van Rossum wrote: > > > >> We're about to start developing for Oracle 9 (or is that 9i???) on > >> Linux. I know that there are several Oracle extensions for Python, > >> but I've never used either of them. If you have relevant experience, > >> please let me know (private mail will be fine). > >> > >> --Guido van Rossum (home page: http://www.python.org/~guido/) > >> > >> _______________________________________________ > >> DB-SIG maillist - DB-SIG@python.org > >> http://mail.python.org/mailman/listinfo/db-sig > > > > > > Guido, > > > > There are two that I know of and have used successfully; > > > > cx_Oracle : http://www.computronix.com/utilities.shtml#Oracle > > DCOracle2 : http://www.zope.org/Members/matt/dco2 > > > > cx_Oracle is more actively maintained (and there are a number of other > > Oracle utilities on that page) but both work well. > > > > It's 9i by the way. Unless you've managed to get an early copy of 10g ;-) > > > > Regards, > > Andy > > but when threadsafety is important, have a closer look to the docs of > the modules. Hmm, yes. It looks like the DCOracle2 module is not following the specification correctly -- or my understanding is flawed and I'd appreciate some correction.... :-) The DCOracle2 module states the following: DCOracle2.threadsafety - this is the thread-safety-ness of DCOracle2, the constant 3. This means that threads may share the module, connections and cursors. Note that programming errors are still possible without a mutex to serialize resources between threads. Note carefully the last statement which conflicts with the statement from the DB API which I reproduce here. Sharing in the above context means that two threads may use a resource without wrapping it using a mutex semaphore to implement resource locking. Note that you cannot always make external resources thread safe by managing access using a mutex: the resource may rely on global variables or other external sources that are beyond your control. Note the first statement in the specification. My own testing has demonstrated quite clearly that even with OCI_THREADED mode, you __CANNOT__ share cursors with multiple threads without using a mutex. Just for fun, try running this code with DCOracle2 -- watch it crash and burn.... :-) I believe DCOracle2's documentation is inaccurate. Anyone care to set me straight?? import threading import DCOracle2 connection = DCOracle2.connect("app/dev@dev") cursor = connection.cursor() def PerformQuery(threadNum): cursor.execute("select count(*) from SOMETABLE") count, = cursor.fetchone() print threadNum, "Count:", count print "Starting threads...." threads = [] for i in range(15): thread = threading.Thread(None, PerformQuery, args = (i,)) threads.append(thread) thread.start() for thread in threads: thread.join() print "All done...." > Regards, > Martin > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From dieter at handshake.de Tue Nov 18 14:05:52 2003 From: dieter at handshake.de (Dieter Maurer) Date: Tue Nov 18 15:41:27 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True In-Reply-To: References: <3FB8ECD9.5080708@ghaering.de> Message-ID: <16314.28048.196390.379121@gargle.gargle.HOWL> Denis S. Otkidach wrote at 2003-11-17 19:39 +0300: > Only 1) and 2) are acceptable. Rollback MUST raise exception if > it ever called since transaction can't be rolled back. I disagree: the transaction can be rolled back, at it is always empty... But, as was already pointed out: the DB-API specification gives you right and me wrong. -- Dieter From ods at strana.ru Wed Nov 19 03:52:31 2003 From: ods at strana.ru (Denis S. Otkidach) Date: Wed Nov 19 04:18:59 2003 Subject: [DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True In-Reply-To: <16314.28048.196390.379121@gargle.gargle.HOWL> Message-ID: On Tue, 18 Nov 2003, Dieter Maurer wrote: DM> > Only 1) and 2) are acceptable. Rollback MUST raise DM> exception if DM> > it ever called since transaction can't be rolled back. DM> DM> I disagree: the transaction can be rolled back, at it is DM> always empty... DM> DM> But, as was already pointed out: the DB-API specification DM> gives you DM> right and me wrong. BTW, I dislike implicit transactions as specified in DB API and prefer to execute BEGIN explicitly in auto-commit mode. Together with multilevel transaction objects (see http://cvs.sf.net/viewcvs.py/ppa/qps/qDB/qSQL.py?rev=HEAD&view=auto for sample implementation) it's the most convenient way to use transactions in OO programs. -- "Explicit is better than implicit" (The Zen of Python by Tim Peters) -- Denis S. Otkidach http://www.python.ru/ [ru] From hmerrill at redhat.com Wed Nov 19 10:17:40 2003 From: hmerrill at redhat.com (Hardy Merrill) Date: Wed Nov 19 10:17:44 2003 Subject: [DB-SIG] new to list - subclass of 'MySQLdb'?? Message-ID: <20031119151740.GA21914@merrill.boston.redhat.com> I'm new to this list, and just started experimenting with database access with Python. I come from the Perl world where Perl DBI is the "standard" for database access in Perl. I've chosen MySQL to start with, so I downloaded MySQLdb and installed it(from source). So, noticing that I have to 'import MySQLdb' and then refer to MySQLdb-specific functions, like MySQLdb.connect(blah blah) I thought I'd try to find or write a database independent layer so that I could do something like MyDB.py ------- #!/usr/bin/python import MySQLdb class MyDB(MySQLdb): def __init__(self): MySQLdb.__init__(self) test.py ------- #!/usr/bin/python import MyDB mydb = MyDB() conn = MyDB.connect(db="mydatabase", user="myuser", passwd="mypass") to make the code more generic and more portable if I were to change the database in the future. This doesn't work - when I run test.py I get this error: [hmerrill@merrill mysqldb]$ ./test.py Traceback (most recent call last): File "./test.py", line 3, in ? mydb = MyDB() TypeError: 'module' object is not callable Am I doing this wrong? How *should* I be doing this? Anyone have some similar code they can show me to start me off in the right direction for subclassing MySQLdb to create a db independent interface to the MySQLdb module? TIA. -- Hardy Merrill Red Hat, Inc. From ods at strana.ru Wed Nov 19 11:39:15 2003 From: ods at strana.ru (Denis S. Otkidach) Date: Wed Nov 19 11:39:23 2003 Subject: [DB-SIG] new to list - subclass of 'MySQLdb'?? In-Reply-To: <20031119151740.GA21914@merrill.boston.redhat.com> Message-ID: On Wed, 19 Nov 2003, Hardy Merrill wrote: HM> I thought I'd try to find or write a database independent HM> layer so that I could do something like HM> HM> MyDB.py HM> ------- HM> #!/usr/bin/python HM> HM> import MySQLdb HM> HM> class MyDB(MySQLdb): HM> def __init__(self): HM> MySQLdb.__init__(self) HM> HM> test.py HM> ------- HM> #!/usr/bin/python HM> import MyDB You should use "from MyDB import MyDB" instead. HM> mydb = MyDB() HM> conn = MyDB.connect(db="mydatabase", user="myuser", HM> passwd="mypass") HM> HM> to make the code more generic and more portable if I were HM> to change the database in the future. HM> HM> This doesn't work - when I run test.py I get this error: HM> HM> [hmerrill@merrill mysqldb]$ ./test.py HM> Traceback (most recent call last): HM> File "./test.py", line 3, in ? HM> mydb = MyDB() HM> TypeError: 'module' object is not callable HM> HM> Am I doing this wrong? How *should* I be doing this? HM> Anyone -- Denis S. Otkidach http://www.python.ru/ [ru] From chris at cogdon.org Wed Nov 19 11:45:27 2003 From: chris at cogdon.org (Chris Cogdon) Date: Wed Nov 19 11:45:36 2003 Subject: [DB-SIG] new to list - subclass of 'MySQLdb'?? In-Reply-To: <20031119151740.GA21914@merrill.boston.redhat.com> References: <20031119151740.GA21914@merrill.boston.redhat.com> Message-ID: On Nov 19, 2003, at 07:17, Hardy Merrill wrote: > I'm new to this list, and just started experimenting with > database access with Python. I come from the Perl world > where Perl DBI is the "standard" for database access in > Perl. > > I've chosen MySQL to start with, so I downloaded > MySQLdb and installed it(from source). So, noticing that > I have to 'import MySQLdb' and then refer to MySQLdb-specific > functions, like > > MySQLdb.connect(blah blah) > > I thought I'd try to find or write a database independent > layer so that I could do something like > > MyDB.py > ------- > #!/usr/bin/python > > import MySQLdb > > class MyDB(MySQLdb): > def __init__(self): > MySQLdb.__init__(self) > > test.py > ------- > #!/usr/bin/python > import MyDB > mydb = MyDB() > conn = MyDB.connect(db="mydatabase", user="myuser", passwd="mypass") > > to make the code more generic and more portable if I were > to change the database in the future. > > This doesn't work - when I run test.py I get this error: > > [hmerrill@merrill mysqldb]$ ./test.py > Traceback (most recent call last): > File "./test.py", line 3, in ? > mydb = MyDB() > TypeError: 'module' object is not callable > > Am I doing this wrong? How *should* I be doing this? Anyone > have some similar code they can show me to start me off in > the right direction for subclassing MySQLdb to create a db > independent interface to the MySQLdb module? When you subclass, you need to subclass a CLASS, and not a MODULE. The 'connect' function is just that, a function that will return an instance of a Connection to the database. To subclass this, you, unfortunately, need to know a little more about the internal structure of the MySQLdb package, and this means looking at the source. Looking at MySQLdb/__init__.py you'll see that 'connect' is aliased to a Connect function. This in turn will import Connection from the MySQLdb/connections.py module, so we need to look at that: In there, we see that Connection is indeed a standard class, so if we wanted, we could subclass that: import MySQLdb.connections class MyDB ( MySQLdb.connections.Connection ): def __init__ ( self, *args, **kwargs ): MySQLdb.connections.Connection ( self, *args, **kwargs ) Note how I'm doing the arguments, too. Now, this can get really messy, and you'll need to 'track' any changes made to the MySQLdb module with your own code. Ick. A BETTER way to handle this is to write a 'wrapper' rather than 'subclass'. Like this: class MyDB: def __init__ ( self, *args, **kwargs ): self.db = MySQLdb.connect ( *args, **kwargs ) And then you can expose whatever functions of the underlying DB through use of stub methods. Eg: def cursor ( self, *args, **kwargs ): return self.db.cursor ( *args, **kwargs ) However, what using this method allows you to do is to hide the SQL implementation completely from the users of your MyDB. Ie, anything that creates an instance of MyDB can be shielded from the SQL implementation completely. So... ignore the 'cursor' method above, and instead code things like this: def add_user ( self, user ): try: cur = self.db.cursor () cur.execute ( "insert into users (id,name,shoe_size) values ( %(id)s, %(name)s, %(shoe_size)s )", user.__dict__ ) self.db.commit () except: self.db.rollback () raise If you end up with a LOT of methods, you can use the 'mix-in' to split your functions over a number of modules: db_users.py: class MyDBUsers: # All your methods relating to users db_cars.py: class MyDBCars: # All your methods relating to cars my_db.py import db_users, db_cars: class MyDB ( db_users.MyDBUsers, db_cars.MyDBCars ): # All your 'generic methods' And, when you create a MyDB, you get ALL the methods just as if they were defined in the same module. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From chris at cogdon.org Wed Nov 19 11:46:51 2003 From: chris at cogdon.org (Chris Cogdon) Date: Wed Nov 19 11:46:58 2003 Subject: [DB-SIG] new to list - subclass of 'MySQLdb'?? In-Reply-To: References: Message-ID: On Nov 19, 2003, at 08:39, Denis S. Otkidach wrote: > You should use "from MyDB import MyDB" instead. Ah yes, that too, but there's also an underlying problem on how he's getting to the MySQL class. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From pf_moore at yahoo.co.uk Thu Nov 20 16:01:42 2003 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Thu Nov 20 16:11:07 2003 Subject: [DB-SIG] cx_Oracle - passing unnecessary bind variables Message-ID: I'm trying to write a function, using cx_Oracle, which allows the user to specify a SQL statement, to be executed with some bind variables out of a common set. Example: class Collector: def __init__(self, cn, **kws): self.vars = kws def execute(sql): c = cn.cursor() c.execute(sql, self.vars) c.close() This is a simplified example, but the basic usage is something like this: cn = cx_Oracle.connect(...) coll = Collector(cn, a=12, b=24, c=11, d=13) coll.execute("insert into t1 (a,b) values(:a, :b)") coll.execute("insert into t2 (a,c,d) values(:a, :c, :d)") The problem is that this doesn't work - it returns an Oracle error, cx_Oracle.DatabaseError: ORA-01036: illegal variable name/number. OK, this is to some extent a limitation of Oracle (or maybe of cx_Oracle, I don't know how Oracle OCI works at this low a level) - I'm passing bind variables which aren't used by the SQL statement. But is there any way of doing something like this? One option is to scan the SQL manually - something like rx = re.compile(":\w+") vars = [m.group()[1:] for m in rx.finditer(sql)] bindvars = {} for var in vars: try: bindvars[var] = self.vars[var] except KeyError: pass but (a) that's very messy, and (b) it's fragile - consider sql = "select a || ':b' from t where a = :a"... Can anyone suggest anything better? Thanks, Paul. -- This signature intentionally left blank From anthony at computronix.com Thu Nov 20 16:27:37 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Thu Nov 20 16:27:47 2003 Subject: [DB-SIG] cx_Oracle - passing unnecessary bind variables In-Reply-To: References: Message-ID: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> On Thu, 2003-11-20 at 14:01, Paul Moore wrote: > I'm trying to write a function, using cx_Oracle, which allows the user > to specify a SQL statement, to be executed with some bind variables > out of a common set. > > Example: > > class Collector: > def __init__(self, cn, **kws): > self.vars = kws > def execute(sql): > c = cn.cursor() > c.execute(sql, self.vars) > c.close() > > This is a simplified example, but the basic usage is something like > this: > > cn = cx_Oracle.connect(...) > coll = Collector(cn, a=12, b=24, c=11, d=13) > coll.execute("insert into t1 (a,b) values(:a, :b)") > coll.execute("insert into t2 (a,c,d) values(:a, :c, :d)") > > The problem is that this doesn't work - it returns an Oracle error, > cx_Oracle.DatabaseError: ORA-01036: illegal variable name/number. > > OK, this is to some extent a limitation of Oracle (or maybe of > cx_Oracle, I don't know how Oracle OCI works at this low a level) - > I'm passing bind variables which aren't used by the SQL statement. But This is definitely a limitation of Oracle. Oracle does not allow you to specify variables that are not part of the statement. As far as I know there is no way around this. Oracle does provide a way of returning to you the bind variable names once the statement is prepared but cx_Oracle does not (currently) provide that information. I have another workaround for now but if you really think this would be helpful, feel free to ask me for it -- this is definitely beyond the scope of the DB API but I have long since stopped feeling restricted by the limitations of the API (which has to accommodate each of the different database management systems out there). > is there any way of doing something like this? One option is to scan > the SQL manually - something like > > rx = re.compile(":\w+") > vars = [m.group()[1:] for m in rx.finditer(sql)] > bindvars = {} > for var in vars: > try: > bindvars[var] = self.vars[var] > except KeyError: > pass > > but (a) that's very messy, and (b) it's fragile - consider > sql = "select a || ':b' from t where a = :a"... Oracle does make this information available once the statement is prepared but if you want something quicker (but less "nice") than I can suggest the following: class Collector: def __init__(self, connection, **args): self.connection = connection self.args = args def execute(self, sql, *args): realArgs = {} for arg in args: realArgs[arg] = self.args[arg] cursor = self.connection.cursor() cursor.execute(sql, **realArgs) with the examples above being translated to: cn = cx_Oracle.connect(...) coll = Collector(cn, a=12, b=24, c=11, d=13) coll.execute("insert into t1 (a, b) values (:a, :b)", "a", "b") coll.execute("insert into t1 (a, c, d) values (:a, :c, :d)", "a", "c", "d") > Can anyone suggest anything better? Not sure if this is "better" or not. Let me know... :-) > Thanks, > Paul. -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From pf_moore at yahoo.co.uk Thu Nov 20 16:51:32 2003 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Thu Nov 20 16:53:24 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> Message-ID: Anthony Tuininga writes: > This is definitely a limitation of Oracle. Oracle does not allow you to > specify variables that are not part of the statement. As far as I know > there is no way around this. I thought that would be the case. > Oracle does provide a way of returning to you the bind variable > names once the statement is prepared but cx_Oracle does not > (currently) provide that information. I have another workaround for > now but if you really think this would be helpful, feel free to ask > me for it -- this is definitely beyond the scope of the DB API but I > have long since stopped feeling restricted by the limitations of the > API (which has to accommodate each of the different database > management systems out there). It's pretty specialised, so I can't say I feel a burning need for it, but it might be nice to have available. I agree with you over DB-API compatibility. It's very good to have a standardised subset, but for real applications (even small ones) I'd generally prefer to be able to get at database-specific features, and use them to exploit the features of the database. > Oracle does make this information available once the statement is > prepared but if you want something quicker (but less "nice") than I can > suggest the following: Yes, I actually thought of that just a couple of minutes ago. It's perfectly adequate, I'd say - a clear case of "practicality beats purity". Thanks for the help! Paul. PS On an unrelated note, have you considered using the Python 2.3 datetime objects instead of cx_Oracle's Date/Time/Timestamp types? I believe that you could do this with virtually no change to the visible API - you'd lose the "fsecond" attribute of the date object, but I think that's all. It would make interacting with standard Python a little less tedious... -- This signature intentionally left blank From anthony at computronix.com Thu Nov 20 17:10:00 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Thu Nov 20 17:10:08 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> Message-ID: <1069366200.29794.43.camel@chl0122.edmonton.computronix.com> On Thu, 2003-11-20 at 14:51, Paul Moore wrote: > Anthony Tuininga writes: > > > Oracle does provide a way of returning to you the bind variable > > names once the statement is prepared but cx_Oracle does not > > (currently) provide that information. I have another workaround for > > now but if you really think this would be helpful, feel free to ask > > me for it -- this is definitely beyond the scope of the DB API but I > > have long since stopped feeling restricted by the limitations of the > > API (which has to accommodate each of the different database > > management systems out there). > > It's pretty specialised, so I can't say I feel a burning need for it, > but it might be nice to have available. I agree with you over DB-API > compatibility. It's very good to have a standardised subset, but for > real applications (even small ones) I'd generally prefer to be able to > get at database-specific features, and use them to exploit the > features of the database. I'll see how simple this is to accomplish. If it is easy and I have the time, I'll add it; otherwise, I'll leave it alone. > > Oracle does make this information available once the statement is > > prepared but if you want something quicker (but less "nice") than I can > > suggest the following: > > Yes, I actually thought of that just a couple of minutes ago. It's > perfectly adequate, I'd say - a clear case of "practicality beats > purity". > > Thanks for the help! No problem. > Paul. > > PS On an unrelated note, have you considered using the Python 2.3 > datetime objects instead of cx_Oracle's Date/Time/Timestamp types? > I believe that you could do this with virtually no change to the > visible API - you'd lose the "fsecond" attribute of the date > object, but I think that's all. It would make interacting with > standard Python a little less tedious... Definitely thought about it. Intending to implement it as well as the ability to subclass connections, cursors, etc. That scale of changes suggests to me 4.0 and will eliminate support for Python 2.1 and earlier. That said, I have branched in CVS so if anyone really needs a change that is compatible with Python 2.1 or earlier it won't be a problem. -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From bgailer at alum.rpi.edu Thu Nov 20 20:42:53 2003 From: bgailer at alum.rpi.edu (Bob Gailer) Date: Thu Nov 20 20:43:07 2003 Subject: [DB-SIG] cx_Oracle - passing unnecessary bind variables In-Reply-To: References: Message-ID: <6.0.0.22.0.20031120183936.029e9d88@mail.mric.net> At 02:01 PM 11/20/2003, Paul Moore wrote: >I'm trying to write a function, using cx_Oracle, which allows the user >to specify a SQL statement, to be executed with some bind variables >out of a common set. > >Example: > > class Collector: > def __init__(self, cn, **kws): > self.vars = kws > def execute(sql): > c = cn.cursor() > c.execute(sql, self.vars) > c.close() > >This is a simplified example, but the basic usage is something like >this: > > cn = cx_Oracle.connect(...) > coll = Collector(cn, a=12, b=24, c=11, d=13) > coll.execute("insert into t1 (a,b) values(:a, :b)") > coll.execute("insert into t2 (a,c,d) values(:a, :c, :d)") Here's what I do: cn.execute("INSERT INTO table1 (col1, col2) VALUES(:id, :key)", id = 1, key = 2) Bob Gailer bgailer@alum.rpi.edu 303 442 2625 -------------- next part -------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 11/10/2003 From jfranz at neurokode.com Fri Nov 21 14:48:40 2003 From: jfranz at neurokode.com (Jon Franz) Date: Fri Nov 21 14:43:34 2003 Subject: [DB-SIG] Parameters, setinputsize and cx_Oracle Message-ID: <062001c3b068$76deb4e0$7401a8c0@voidmk9> Hello, I seem to be having some issues with LONG fields when using cx_Oracle. Specifically, it is behaving as if .setinputsizes() is not being called, or is being called with a different value then what was passed - resulting in truncated data. I hope I'm just doing soemthign wrong. The really odd part is, the truncation size isn't always the same - but I'll get to that in a moment. First, my platform: Windows XP pro, Oracle enterprise 9i, Python 2.3.2, cx_Oracle 3.1 Now, some examples: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import cx_Oracle >>> mycon = cx_Oracle.connect("cx_Oracle","dev","PDOTEST") >>> cursor = mycon.cursor() >>> bigtext = "123456789z" * 9000 >>> len(bigtext) 90000 >>> cursor.setinputsizes(big = len(bigtext)) {'big': } >>> cursor.execute("INSERT INTO TESTLONGS (INTCOL, LONGCOL) VALUES (111, :big)", { "big" : bigtext }) >>> cursor.setoutputsize(200000) # bigger than needed >>> cursor.execute("SELECT * FROM TESTLONGS WHERE INTCOL = 111") [, ] >>> row = cursor.fetchone() >>> len(row[1]) 24464 >>> ---------- Now, at first I thought I was doing something wrong with .setoutputsize() - but the examples I'm finding do things the same way - and using the form of .setoutputsize(200000, 2) (as seen within the LongVar.py test script from the source dist) has the same problem. If I commit and examine the row within Oracle Enterprise Manager, I get the same length as above for the row - so that leads me to believe I'm not doing something wrong pulling data out, but something is going wrong on the way in... Each time I try this, I get the same results, a truncated value - but the length is not always 24464: sometimes it is 48032 - so it is not consistently 24464. Am I doing something wrong at insert time, or somewhere else? Note: passing a dict to setinputsizes() results in these same problems. ~Jon Franz NeuroKode Labs, LLC From pf_moore at yahoo.co.uk Sun Nov 23 14:31:55 2003 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Sun Nov 23 14:30:23 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> Message-ID: Anthony Tuininga writes: > On Thu, 2003-11-20 at 14:01, Paul Moore wrote: >> The problem is that this doesn't work - it returns an Oracle error, >> cx_Oracle.DatabaseError: ORA-01036: illegal variable name/number. >> >> OK, this is to some extent a limitation of Oracle (or maybe of >> cx_Oracle, I don't know how Oracle OCI works at this low a level) - >> I'm passing bind variables which aren't used by the SQL statement. But > > This is definitely a limitation of Oracle. Oracle does not allow you to > specify variables that are not part of the statement. As far as I know > there is no way around this. Oracle does provide a way of returning to > you the bind variable names once the statement is prepared but cx_Oracle > does not (currently) provide that information. I have another workaround > for now but if you really think this would be helpful, feel free to ask > me for it -- this is definitely beyond the scope of the DB API but I > have long since stopped feeling restricted by the limitations of the API > (which has to accommodate each of the different database management > systems out there). The behaviour of cursor.execute(sql, parameters) when there are variables specified in `parameters` which are not needed by `sql` is undefined in the DB-API. However, the more I think about it, the more I feel that ignoring "extra" parameters is the more user-friendly option. The cons: * It's potentially harder for module authors to implement (as you pointed out for Oracle) * It may be slower in cases where it's not needed. * It could hide typos (but they'd have to be pretty obscure - include an extra, misspelled, variable, but still include the variable by its "correct" name as well) The pros: * Supports using the same parameter dictionary for multiple SQL statements. * There is no easy way to do this in user code (you can't get the list of bind variables used by a cursor, so you have to work around it by making the user pass the variables, like we said). * This is DB-API compliant (if not mandated). It's only relevant for paramstyles of 'named' and 'pyformat', so it doesn't apply to all of the modules out there. I checked a few of the modules I could find, mostly by just looking at the documented paramstyle: Module Paramstyle Notes ---------- ---------- ----------------------------- mxODBC qmark not relevant DCOracle2 numeric not relevant [1] pysqlite pyformat ignores extra arguments adodbapi qmark not relevant psycopg pyformat ignores extra arguments [2] pyPgSQL pyformat ignores extra arguments [2] Sybase named can't test Ingres ? can't test [1] It's a pity DCOracle2 uses numeric arguments, as this is the closest equivalent to cx_Oracle (in terms of what is needed for implementation, at least). [2] I don't have Postgres to test, but scanning the implementation, it seems to use the normal Python % operations to build the SQL from the arguments, so it should ignore extra arguments. Does anyone have any thoughts? Obviously, I'm not in any position to insist that things work this way. If I knew more about OCI coding, I'd try to supply a patch (I may see what I can do anyway - I assume it's OCIStmtGetBindInfo() that's relevant here?) Paul. PS Actually, on reflection, there's a comparable question for positional styles - can you have a parameter sequence that's longer than needed? I don't think this is as important, though - but that may just reflect my personal view that named bindings are far more useful than positional ones. [FWIW, though, I did a quick check and mxODBC, at least, rejects parameter lists of the wrong length] -- This signature intentionally left blank From anthony at computronix.com Mon Nov 24 10:22:53 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Mon Nov 24 10:23:05 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> Message-ID: <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> On Sun, 2003-11-23 at 12:31, Paul Moore wrote: > Anthony Tuininga writes: > > > On Thu, 2003-11-20 at 14:01, Paul Moore wrote: > >> The problem is that this doesn't work - it returns an Oracle error, > >> cx_Oracle.DatabaseError: ORA-01036: illegal variable name/number. > >> > >> OK, this is to some extent a limitation of Oracle (or maybe of > >> cx_Oracle, I don't know how Oracle OCI works at this low a level) - > >> I'm passing bind variables which aren't used by the SQL statement. But > > > > This is definitely a limitation of Oracle. Oracle does not allow you to > > specify variables that are not part of the statement. As far as I know > > there is no way around this. Oracle does provide a way of returning to > > you the bind variable names once the statement is prepared but cx_Oracle > > does not (currently) provide that information. I have another workaround > > for now but if you really think this would be helpful, feel free to ask > > me for it -- this is definitely beyond the scope of the DB API but I > > have long since stopped feeling restricted by the limitations of the API > > (which has to accommodate each of the different database management > > systems out there). > > The behaviour of cursor.execute(sql, parameters) when there are > variables specified in `parameters` which are not needed by `sql` is > undefined in the DB-API. However, the more I think about it, the more > I feel that ignoring "extra" parameters is the more user-friendly > option. I've never been a fan of ignoring errors, even ones that appear "safe" to ignore. I also prefer explicit to implicit -- in other words, I wouldn't mind implementing something like this as an __option__ that can be explicitly chosen. Of course, I'm also willing to entertain additional arguments for why this is a "good thing". :-) > The cons: > > * It's potentially harder for module authors to implement (as you > pointed out for Oracle) Actually, if all you care to do is ignore the error, you can quite easily do that. In other words, check for ORA-1036 (illegal variable name/number) and simply ignore it and move on. See above for why I'm not really all that comfortable with this. > * It may be slower in cases where it's not needed. Somewhat, true. Of course, if you code everything correctly, there is no issue. If you add extra parameters accidentally, they will be ignored. > * It could hide typos (but they'd have to be pretty obscure - include > an extra, misspelled, variable, but still include the variable by > its "correct" name as well) True. This one is pretty minor. > The pros: > > * Supports using the same parameter dictionary for multiple SQL > statements. Since cx_Oracle allows keyword arguments for executing SQL statements, this one has not proved to be a problem to me. This is something that I wish the DB API standard would "officially" endorse. Specifically, this is permitted in cx_Oracle: cursor.execute(sql, var1=value1, var2=value2, var3=value3....) which allows for the building of a dictionary quite easily. There are a few cases where it might be convenient to pass a prebuilt dictionary but they are few and far between -- unless you can give me some additional examples?? > * There is no easy way to do this in user code (you can't get the > list of bind variables used by a cursor, so you have to work > around it by making the user pass the variables, like we said). There is no DB API method for doing so. I have just recently added the necessary code (cursor.bindnames()) to cx_Oracle for those who care to do this. I am also adding the ability to subclass connections and cursors so you can make this extremely transparent. > * This is DB-API compliant (if not mandated). It's only relevant for > paramstyles of 'named' and 'pyformat', so it doesn't apply to all > of the modules out there. True. But here is another case where the DB API is not explicit enough. That means that a module may or may not implement this behavior and thus you cannot count on it. I think I would list this as a con.... :-) > I checked a few of the modules I could find, mostly by just > looking at the documented paramstyle: > > Module Paramstyle Notes > ---------- ---------- ----------------------------- > mxODBC qmark not relevant > DCOracle2 numeric not relevant [1] > pysqlite pyformat ignores extra arguments > adodbapi qmark not relevant > psycopg pyformat ignores extra arguments [2] > pyPgSQL pyformat ignores extra arguments [2] > Sybase named can't test > Ingres ? can't test > > [1] It's a pity DCOracle2 uses numeric arguments, as this is the > closest equivalent to cx_Oracle (in terms of what is needed for > implementation, at least). > > [2] I don't have Postgres to test, but scanning the implementation, it > seems to use the normal Python % operations to build the SQL from > the arguments, so it should ignore extra arguments. > > Does anyone have any thoughts? Obviously, I'm not in any position to > insist that things work this way. If I knew more about OCI coding, I'd > try to supply a patch (I may see what I can do anyway - I assume it's > OCIStmtGetBindInfo() that's relevant here?) You can e-mail me directly if you wish more information on this. Perhaps what I have already implemented will make this work for you and if not, I'm willing to entertain suggestions.... :-) > Paul. > > PS Actually, on reflection, there's a comparable question for > positional styles - can you have a parameter sequence that's longer > than needed? I don't think this is as important, though - but that > may just reflect my personal view that named bindings are far more > useful than positional ones. [FWIW, though, I did a quick check and Tell me about it. The code makes considerably more sense when using named bind variables. The qmark paramstyle is the worst as the mapping is that much harder to do in your head. > mxODBC, at least, rejects parameter lists of the wrong length] With an error, right? I think that makes the most sense. And if that makes sense, perhaps raising an error when a named variable does not exist in the statement also makes sense, eh??? :-) -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From dieter at handshake.de Mon Nov 24 13:00:39 2003 From: dieter at handshake.de (Dieter Maurer) Date: Mon Nov 24 13:30:55 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> Message-ID: <16322.18247.627909.932678@gargle.gargle.HOWL> Anthony Tuininga wrote at 2003-11-24 08:22 -0700: > ... > Since cx_Oracle allows keyword arguments for executing SQL statements, > this one has not proved to be a problem to me. This is something that I > wish the DB API standard would "officially" endorse. Specifically, this > is permitted in cx_Oracle: > > cursor.execute(sql, var1=value1, var2=value2, var3=value3....) > > which allows for the building of a dictionary quite easily. There are a > few cases where it might be convenient to pass a prebuilt dictionary but > they are few and far between -- unless you can give me some additional > examples?? That is no longer an issue: When you have a dictionary "d" and you need keyword arguments, you simply pass "**d", e.g.: cursor.execute(sql, **d) -- Dieter From anthony at computronix.com Mon Nov 24 13:32:41 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Mon Nov 24 13:32:48 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: <16322.18247.627909.932678@gargle.gargle.HOWL> References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> <16322.18247.627909.932678@gargle.gargle.HOWL> Message-ID: <1069698761.8125.38.camel@chl0122.edmonton.computronix.com> On Mon, 2003-11-24 at 11:00, Dieter Maurer wrote: > Anthony Tuininga wrote at 2003-11-24 08:22 -0700: > > ... > > Since cx_Oracle allows keyword arguments for executing SQL statements, > > this one has not proved to be a problem to me. This is something that I > > wish the DB API standard would "officially" endorse. Specifically, this > > is permitted in cx_Oracle: > > > > cursor.execute(sql, var1=value1, var2=value2, var3=value3....) > > > > which allows for the building of a dictionary quite easily. There are a > > few cases where it might be convenient to pass a prebuilt dictionary but > > they are few and far between -- unless you can give me some additional > > examples?? > > That is no longer an issue: > > When you have a dictionary "d" and you need keyword arguments, > you simply pass "**d", e.g.: > > cursor.execute(sql, **d) Could you explain exactly what you mean? I believe the syntax you show is invalid in the DB API. Specifically, you must call cursor.execute(sql, d) where d is a dictionary. Keyword arguments are not supported by the DB API but they are with cx_Oracle. Or am I missing something here and you are referring to something else? -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From pf_moore at yahoo.co.uk Mon Nov 24 15:29:17 2003 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Mon Nov 24 15:29:09 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> Message-ID: Anthony Tuininga writes: [...] > There is no DB API method for doing so. I have just recently added the > necessary code (cursor.bindnames()) to cx_Oracle for those who care to > do this. I am also adding the ability to subclass connections and > cursors so you can make this extremely transparent. [...] I'm persuaded. And with these new features, even if I wasn't, I could build a cursor subclass which implemented my proposed behaviour for myself. (When the new version comes out, I probably will use cursor.bindnames() for the one specialised application I hit this issue with). Anthony, thanks once again for a great module, and for your patience and receptiveness when dealing with my dumb questions. Paul. -- This signature intentionally left blank From anthony at computronix.com Mon Nov 24 15:37:12 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Mon Nov 24 15:37:53 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> Message-ID: <1069706232.8125.43.camel@chl0122.edmonton.computronix.com> On Mon, 2003-11-24 at 13:29, Paul Moore wrote: > Anthony Tuininga writes: > > [...] > > There is no DB API method for doing so. I have just recently added the > > necessary code (cursor.bindnames()) to cx_Oracle for those who care to > > do this. I am also adding the ability to subclass connections and > > cursors so you can make this extremely transparent. > [...] > > I'm persuaded. And with these new features, even if I wasn't, I could > build a cursor subclass which implemented my proposed behaviour for > myself. (When the new version comes out, I probably will use > cursor.bindnames() for the one specialised application I hit this > issue with). Glad to hear my arguments are convincing -- at least to you and me... :-) The ability to subclass cursors and connections eliminates all sorts of specialized cases that I would otherwise have to concern myself with. Ah, the wonders of Python 2.2 and the new type model! > Anthony, thanks once again for a great module, and for your patience > and receptiveness when dealing with my dumb questions. You're welcome. And keep asking the "dumb" questions -- they spark thoughts in my mind that otherwise would remain dormant... :-) > Paul. -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From martin at sterling2000.co.uk Tue Nov 25 06:27:52 2003 From: martin at sterling2000.co.uk (martin@sterling2000.co.uk) Date: Tue Nov 25 06:27:58 2003 Subject: [DB-SIG] ADO Message-ID: I have been searching the net for two weeks now but can find nothing on disconnected recordsets. I have been programming in VB6 for two years and have had quite a success with disconnected resordsets with the following code:- Dim acUpdateable As Connection Set acUpdateable = New Connection acUpdateable.Open gBRDataBase Set rsUpdateable = New ADODB.Recordset rsUpdateable.CursorLocation = adUseClient rsUpdateable.LockType = adLockBatchOptimistic rsUpdateable.CursorType = adOpenForwardOnly rsUpdateable.Open sSQL, acUpdateable rsUpdateable.MarshalOptions = adMarshalModifiedOnly Set rsUpdateable.ActiveConnection = Nothing acUpdateable.Close Set acUpdateable = Nothing I can implement most of this within Python but not the bit after Marshalling. I can read and write to the database but as soon as I try to disconnect the recordset Python cannot see the cursor. Is it possible to use disconnected recordsets with Python and if so where can I find information on the subject. Any help you can offer would be gratefully received. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031125/70451ad2/attachment.html From mal at egenix.com Tue Nov 25 06:33:34 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Nov 25 06:33:47 2003 Subject: [DB-SIG] ADO In-Reply-To: References: Message-ID: <3FC33E0E.6060207@egenix.com> martin@sterling2000.co.uk wrote: > I have been searching the net for two weeks now but can find nothing on disconnected recordsets. > > I have been programming in VB6 for two years and have had quite a success with disconnected resordsets with the following code:- > > Dim acUpdateable As Connection > > Set acUpdateable = New Connection > acUpdateable.Open gBRDataBase > > Set rsUpdateable = New ADODB.Recordset > > rsUpdateable.CursorLocation = adUseClient > rsUpdateable.LockType = adLockBatchOptimistic > rsUpdateable.CursorType = adOpenForwardOnly > > rsUpdateable.Open sSQL, acUpdateable > > rsUpdateable.MarshalOptions = adMarshalModifiedOnly > Set rsUpdateable.ActiveConnection = Nothing > acUpdateable.Close > Set acUpdateable = Nothing > > I can implement most of this within Python but not the bit after Marshalling. > > I can read and write to the database but as soon as I try to disconnect the recordset Python cannot see the cursor. > > Is it possible to use disconnected recordsets with Python and if so where can I find information on the subject. > > Any help you can offer would be gratefully received. Why not load the result set into memory and then use iterators to read from it (without an active connection the result will have to be copied into client memory anyway) ? resultset = cursor.fetchall() for row in resultset: .... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 24 2003) >>> Python/Zope Products & Consulting ... 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 ! :::: From dieter at handshake.de Tue Nov 25 15:52:35 2003 From: dieter at handshake.de (Dieter Maurer) Date: Tue Nov 25 16:56:57 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: <1069698761.8125.38.camel@chl0122.edmonton.computronix.com> References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> <16322.18247.627909.932678@gargle.gargle.HOWL> <1069698761.8125.38.camel@chl0122.edmonton.computronix.com> Message-ID: <16323.49427.737746.897741@gargle.gargle.HOWL> Anthony Tuininga wrote at 2003-11-24 11:32 -0700: > ... > > > There are a > > > few cases where it might be convenient to pass a prebuilt dictionary but > > > they are few and far between -- unless you can give me some additional > > > examples?? > > > > That is no longer an issue: > > > > When you have a dictionary "d" and you need keyword arguments, > > you simply pass "**d", e.g.: > > > > cursor.execute(sql, **d) > > Could you explain exactly what you mean? I believe the syntax you show > is invalid in the DB API. The syntax is Python syntax. The DB-API will not see it, as Python will call "execute" with "sql, key1=val1, key2=val2, ..." --- not supported by the DB-API but by your "execute" implementation. -- Dieter From anthony at computronix.com Tue Nov 25 18:01:42 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Tue Nov 25 18:01:51 2003 Subject: [DB-SIG] Re: cx_Oracle - passing unnecessary bind variables In-Reply-To: <16323.49427.737746.897741@gargle.gargle.HOWL> References: <1069363657.29794.38.camel@chl0122.edmonton.computronix.com> <1069687373.8125.24.camel@chl0122.edmonton.computronix.com> <16322.18247.627909.932678@gargle.gargle.HOWL> <1069698761.8125.38.camel@chl0122.edmonton.computronix.com> <16323.49427.737746.897741@gargle.gargle.HOWL> Message-ID: <1069801302.11193.8.camel@chl0122.edmonton.computronix.com> On Tue, 2003-11-25 at 13:52, Dieter Maurer wrote: > Anthony Tuininga wrote at 2003-11-24 11:32 -0700: > > ... > > > > There are a > > > > few cases where it might be convenient to pass a prebuilt dictionary but > > > > they are few and far between -- unless you can give me some additional > > > > examples?? > > > > > > That is no longer an issue: > > > > > > When you have a dictionary "d" and you need keyword arguments, > > > you simply pass "**d", e.g.: > > > > > > cursor.execute(sql, **d) > > > > Could you explain exactly what you mean? I believe the syntax you show > > is invalid in the DB API. > > The syntax is Python syntax. The DB-API will not see it, as > Python will call "execute" with "sql, key1=val1, key2=val2, ..." --- > not supported by the DB-API but by your "execute" implementation. Right. That is what I thought. Just clarifying. -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From uwe.grauer at grauer-online.de Wed Nov 26 09:46:31 2003 From: uwe.grauer at grauer-online.de (Uwe Grauer) Date: Wed Nov 26 09:46:32 2003 Subject: [DB-SIG] kinterbas db column type Message-ID: <3FC4BCC7.6060203@grauer-online.de> Hi, i need to know the database column types returned by kinterbasdb. Implicit type conversion is i nice thing to have, but it hides the real types in the database. So how could i get this information? Thanks, Uwe From gh at ghaering.de Wed Nov 26 10:43:26 2003 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Wed Nov 26 10:43:32 2003 Subject: [DB-SIG] kinterbas db column type In-Reply-To: <3FC4BCC7.6060203@grauer-online.de> References: <3FC4BCC7.6060203@grauer-online.de> Message-ID: <3FC4CA1E.5080805@ghaering.de> Uwe Grauer wrote: > Hi, > > i need to know the database column types returned by kinterbasdb. > Implicit type conversion is i nice thing to have, but it hides the real > types in the database. > So how could i get this information? Quoting the DB-API 2.0 (http://www.python.org/peps/pep-0249.html): .description This read-only attribute is a sequence of 7-item sequences. Each of these sequences contains information describing one result column: (name, type_code, display_size, internal_size, precision, scale, null_ok). The first two items (name and type_code) are mandatory, the other five are optional and must be set to None if meaningfull values are not provided. So you can compare the type_code with the constants in your DB-API module (STRING, NUMBER, ...). If you need the exact data types of table/view columns, you'll probably need to query database meta tables for this information. -- Gerhard From mailinglists at onlinehome.de Wed Nov 26 11:07:45 2003 From: mailinglists at onlinehome.de (Uwe Grauer) Date: Wed Nov 26 11:07:43 2003 Subject: [DB-SIG] kinterbas db column type In-Reply-To: <3FC4CA1E.5080805@ghaering.de> References: <3FC4BCC7.6060203@grauer-online.de> <3FC4CA1E.5080805@ghaering.de> Message-ID: <3FC4CFD1.5040904@onlinehome.de> Gerhard H?ring wrote: > Uwe Grauer wrote: > >> Hi, >> >> i need to know the database column types returned by kinterbasdb. >> Implicit type conversion is i nice thing to have, but it hides the >> real types in the database. >> So how could i get this information? > > > Quoting the DB-API 2.0 (http://www.python.org/peps/pep-0249.html): > > .description > > This read-only attribute is a sequence of 7-item > sequences. Each of these sequences contains information > describing one result column: (name, type_code, > display_size, internal_size, precision, scale, > null_ok). The first two items (name and type_code) are > mandatory, the other five are optional and must be set to > None if meaningfull values are not provided. > > So you can compare the type_code with the constants in your DB-API > module (STRING, NUMBER, ...). > > If you need the exact data types of table/view columns, you'll > probably need to query database meta tables for this information. > > -- Gerhard I know .description, but my question is specific to the kinterbasedb module. It's different from other modules cause it does a implicit type conversion to the Python-types. So for a DATETIME-column in mysql you get a type_code 12 (which is indeed DATETIME in MySQLdb) but in kinterbasdb you get t_tuple. This does not help me very much since the information i need is different from what i get. Uwe From davidrushby at yahoo.com Wed Nov 26 15:05:34 2003 From: davidrushby at yahoo.com (David Rushby) Date: Wed Nov 26 15:05:53 2003 Subject: [DB-SIG] kinterbas db column type In-Reply-To: <3FC4CFD1.5040904@onlinehome.de> Message-ID: <20031126200534.66533.qmail@web11008.mail.yahoo.com> --- Uwe Grauer wrote: > I know .description, but my question is specific to the kinterbasedb > module. > It's different from other modules cause it does a implicit type > conversion to the Python-types. > So for a DATETIME-column in mysql you get a type_code 12 (which is > indeed DATETIME in MySQLdb) but in kinterbasdb you get t_tuple. This > does not help me very much since the information i need is different > from what i get. This is a known problem in 3.1_pre6 and earlier. It's fixed in the CVS version, which I plan to release soon as 3.1_pre7. Here's the relevant SF bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=814276&group_id=9913&atid=109913 If you're not compiler- or CVS- constrained, use the CVS version right now; it's quite stable. __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ From ronald at hondabutton.com.hk Thu Nov 27 21:53:46 2003 From: ronald at hondabutton.com.hk (ronald lam) Date: Thu Nov 27 21:51:24 2003 Subject: [DB-SIG] retrieve data from mysql Message-ID: <3FC6B8BA.4090500@hondabutton.com.hk> I'm a newbie, I want to retrieve data from mysql server, all are normal but non of datas could retrieve from database, it is because wrong select syntags as below: cursor.execute("SELECT descrip, pri, unit FROM code where descrip like '%$siz%' limit 20") Will any Masters help me fixing the sentence '%????%' Rgds ------------------------------------- #!/usr/local/bin/python # import MySQL module import MySQLdb # get user input siz = raw_input("Please enter size: ") #des = raw_input("Please enter description: ") # connect db = MySQLdb.connect(host="fa", user="ron", passwd="xxxxx", db="hon") # create a cursor cursor = db.cursor() # execute SQL statement #cursor.execute("INSERT INTO animals (name, species) VALUES (%s, %s)", #(name, species)) cursor.execute("SELECT descrip, pri, unit FROM code where descrip like '%$siz%' limit 20") result = cursor.fetchall() for record in result: print record[0],'--->', record[1], record[2] From andy47 at halfcooked.com Fri Nov 28 05:36:01 2003 From: andy47 at halfcooked.com (Andy Todd) Date: Fri Nov 28 05:38:45 2003 Subject: [DB-SIG] retrieve data from mysql In-Reply-To: <3FC6B8BA.4090500@hondabutton.com.hk> References: <3FC6B8BA.4090500@hondabutton.com.hk> Message-ID: <3FC72511.8090403@halfcooked.com> ronald lam wrote: > I'm a newbie, I want to retrieve data from mysql server, all are normal > but non of datas could retrieve from database, it is because wrong > select syntags as below: > > cursor.execute("SELECT descrip, pri, unit FROM code where descrip like > '%$siz%' limit 20") > > Will any Masters help me fixing the sentence '%????%' > > Rgds > > ------------------------------------- > > #!/usr/local/bin/python > > # import MySQL module > import MySQLdb > > # get user input > siz = raw_input("Please enter size: ") > #des = raw_input("Please enter description: ") > > # connect > db = MySQLdb.connect(host="fa", user="ron", passwd="xxxxx", > db="hon") > > # create a cursor > cursor = db.cursor() > > # execute SQL statement > #cursor.execute("INSERT INTO animals (name, species) VALUES (%s, %s)", > #(name, species)) > > cursor.execute("SELECT descrip, pri, unit FROM code where descrip like > '%$siz%' limit 20") > result = cursor.fetchall() > for record in result: > print record[0],'--->', record[1], record[2] > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig Ronald, Change your cursor.execute line to cursor.execute("SELECT descrip, pri, unit FROM code WHERE descrip LIKE %s LIMIT 20", ('%'+siz+'%',)) Then read the section of the DB-API on paramstyle (http://www.python.org/peps/pep-0249.html). MySQLdb uses the 'format' style, where you place a '%s' in your statement wherever you wish to substitute another value at run time. Its quite a powerful mechanism. I'd also question whether you need to use a like for a column which looks like it is numeric. But that's just me. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From 9hqpstslol at mindspring.com Sat Nov 29 11:48:07 2003 From: 9hqpstslol at mindspring.com (Marylou Stallings) Date: Sat Nov 29 01:52:12 2003 Subject: [DB-SIG] Keep the colon clean! y u jpngj Message-ID: <2d$3u$9f-4xi$$7$y2$h@49x.nvg> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031129/ab0455c2/attachment.html