From Dzung_Pham-RYEY90@email.sps.mot.com Thu Apr 3 15:50:00 1997 From: Dzung_Pham-RYEY90@email.sps.mot.com (Dzung Pham-RYEY90) Date: Thu, 3 Apr 1997 9:50:00 -0600 Subject: [PYTHON DB-SIG] pickling dbiDate objects Message-ID: pickle can't pickle dbiDate objects. Any ideas or suggestions ? Thanks in advance. Regards, Dzung Pham _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Thu Apr 3 17:43:16 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 03 Apr 1997 12:43:16 -0500 Subject: [PYTHON DB-SIG] pickling dbiDate objects References: Message-ID: <3343EC34.332E@digicool.com> Dzung Pham-RYEY90 wrote: > > pickle can't pickle dbiDate objects. Any ideas or suggestions ? Yes. Use cPickle, http://www.digicool.com/releases/cpickle/. cPickle has a mechanism for telling it how to pickle extension types. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gamboa@austin.ibm.com Mon Apr 14 15:38:08 1997 From: gamboa@austin.ibm.com (Mona E. Gamboa) Date: Mon, 14 Apr 1997 09:38:08 -0500 Subject: [PYTHON DB-SIG] Python Database API Message-ID: <33524150.41C6@austin.ibm.com> Hello, I am creating an Python database API for DB2, ibm's in-house database, and I was wondering if there was a new Python Database API than the one on the web page: http://www.python.org/sigs/db-sig/DatabaseAPI.html The document was last updated April 9, 1996, almost a year ago, and it seems to me that there might have been some work on it since then. Cheers, Mona _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@msn.com Tue Apr 15 01:25:40 1997 From: aaron_watters@msn.com (aaron watters) Date: Tue, 15 Apr 97 00:25:40 UT Subject: [PYTHON DB-SIG] Python Database API Message-ID: Well, that's very exciting I must say. I think there have been various discussions, with particularly good ideas coming from Jim Fulton among others, but usually we end up with "Well, I geuss it's time for someone to solidify all this into a reasonably precise proposal..." and then it just fizzles out. :( The current approach seems reasonably workable, but if you have any questions comments or proposals, we're always willing to listen. Will the DB2 port be for fun, for internal use, for a product, for distribution, all of the above, or you really can't say? Just prying... -- Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Mona E. Gamboa Sent: Monday, April 14, 1997 10:38 AM To: db-sig@python.org Subject: [PYTHON DB-SIG] Python Database API Hello, I am creating an Python database API for DB2, ibm's in-house database, and I was wondering if there was a new Python Database API than the one on the web page: http://www.python.org/sigs/db-sig/DatabaseAPI.html The document was last updated April 9, 1996, almost a year ago, and it seems to me that there might have been some work on it since then. Cheers, Mona _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Tue Apr 15 01:05:41 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 14 Apr 1997 17:05:41 -0700 Subject: [PYTHON DB-SIG] Python Database API Message-ID: <41135C785691CF11B73B00805FD4D2D70261B50E@RED-17-MSG.dns.microsoft.com> The API is stable and has not changed since then. There are some changes to DBI (as mentioned) that have not been documented yet. The "spec" for that can be found via the code of the various other modules (odbc, oracle, informix). There have been a number of discussions about changes to the API, but nothing has arisen yet; most of the suggestions have been relegated to Python layers on top of the underlying database modules. -g -----Original Message----- From: Mona E. Gamboa [SMTP:gamboa@austin.ibm.com] Sent: Monday, April 14, 1997 7:38 AM To: db-sig@python.org Subject: [PYTHON DB-SIG] Python Database API Hello, I am creating an Python database API for DB2, ibm's in-house database, and I was wondering if there was a new Python Database API than the one on the web page: http://www.python.org/sigs/db-sig/DatabaseAPI.html The document was last updated April 9, 1996, almost a year ago, and it seems to me that there might have been some work on it since then. Cheers, Mona _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Tue Apr 15 05:30:44 1997 From: Anthony Baxter (Anthony Baxter) Date: Tue, 15 Apr 1997 14:30:44 +1000 Subject: [PYTHON DB-SIG] Python Database API In-Reply-To: Your message of "Mon, 14 Apr 1997 17:05:41 MST." <41135C785691CF11B73B00805FD4D2D70261B50E@RED-17-MSG.dns.microsoft.com> Message-ID: <199704150430.OAA01105@jambu.off.connect.com.au> >>> Greg Stein wrote > The API is stable and has not changed since then. There are some changes > to DBI (as mentioned) that have not been documented yet. The "spec" for > that can be found via the code of the various other modules (odbc, > oracle, informix). FWIW, I'd like to fill in a few of the "not well defined yet" bits - I'm currently rewriting the oracle module (amongst other things, to get more than one row at a time, and to use the thread-safe interfaces of Oracle 7.3) As far as I can see, there's no spec for the DBI stuff. I'd like to be able to specify creation of dbiDates, using either a delta, or a 7-tuple, as produced by time.gmtime() and friends. The current oracle module forces everything to be done in terms of localtime, which is bad. Other things: currently the spec says connection.close() should render the connection unusable, and any attempts to use the connection should raise an exception. Should this also apply to any cursors created from the connection? What about cursor.close()? Should that just nuke the current cursor, or the connection it's attached to? Has anyone done anything with connection.callproc() at all? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Apr 16 03:55:08 1997 From: gstein@microsoft.com (Greg Stein) Date: Tue, 15 Apr 1997 19:55:08 -0700 Subject: [PYTHON DB-SIG] Python Database API Message-ID: <41135C785691CF11B73B00805FD4D2D70277BBE3@RED-17-MSG.dns.microsoft.com> Hmm. I thought there was a spec for DBI (just checked... there is, but it doesn't cover the "generic" exceptions). Personally, I have no objections to your extensions, but I'd recommend ensuring that your changes get propagated to the other DBAPI modules. It might be worth it to have somebody step up as the "owner" of the DBI as a separate entity. It would be available separately, but the modules simply repackage it. If you could write a spec for your new DBI to go along with what you code, and nobody has any objections, then we can plop that up onto the web site. I would say that any cursors associated with a closed connection become unusable. Closing cursors should not have an impact on the connection. I've never dealt with callproc. In truth, I'm not positive that it is needed after all. It seems to be quite possible to simply use execute() for store procedures in addition to (SQL) statements. One interesting note: the ODBC module is apparently quite fast relatively to other mechanisms available to Python for accessing databases (e.g. ADO). You can *make* ADO go faster, but it takes a good amount of fine tuning and voodoo. Empirically, the ODBC module is simple to use (love that API!) and capable of being quite efficient. To fetch/insert more than one row at a time, are you using the row count from fetchmany() and/or the arraysize attribute? -g -----Original Message----- From: Anthony Baxter [SMTP:arb@connect.com.au] Sent: Monday, April 14, 1997 9:31 PM To: Greg Stein Cc: 'Mona E. Gamboa'; db-sig@python.org Subject: Re: [PYTHON DB-SIG] Python Database API >>> Greg Stein wrote > The API is stable and has not changed since then. There are some changes > to DBI (as mentioned) that have not been documented yet. The "spec" for > that can be found via the code of the various other modules (odbc, > oracle, informix). FWIW, I'd like to fill in a few of the "not well defined yet" bits - I'm currently rewriting the oracle module (amongst other things, to get more than one row at a time, and to use the thread-safe interfaces of Oracle 7.3) As far as I can see, there's no spec for the DBI stuff. I'd like to be able to specify creation of dbiDates, using either a delta, or a 7-tuple, as produced by time.gmtime() and friends. The current oracle module forces everything to be done in terms of localtime, which is bad. Other things: currently the spec says connection.close() should render the connection unusable, and any attempts to use the connection should raise an exception. Should this also apply to any cursors created from the connection? What about cursor.close()? Should that just nuke the current cursor, or the connection it's attached to? Has anyone done anything with connection.callproc() at all? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Wed Apr 16 06:46:43 1997 From: Anthony Baxter (Anthony Baxter) Date: Wed, 16 Apr 1997 15:46:43 +1000 Subject: [PYTHON DB-SIG] Python Database API In-Reply-To: Your message of "Tue, 15 Apr 1997 19:55:08 MST." <41135C785691CF11B73B00805FD4D2D70277BBE3@RED-17-MSG.dns.microsoft.com> Message-ID: <199704160546.PAA05056@jambu.off.connect.com.au> >>> Greg Stein wrote > Hmm. I thought there was a spec for DBI (just checked... there is, but > it doesn't cover the "generic" exceptions). Personally, I have no I will document what I've done, and add it in. I'd _like_ to see dbi become a seperate module, so we can share the code across all who use it. I'm just not sure how independant it can be. > I would say that any cursors associated with a closed connection become > unusable. Closing cursors should not have an impact on the connection. Yep. This should go into the API. > I've never dealt with callproc. In truth, I'm not positive that it is > needed after all. It seems to be quite possible to simply use execute() > for store procedures in addition to (SQL) statements. Ok, well, is _anyone_ using it? If not, can we drop it from the API? > One interesting note: the ODBC module is apparently quite fast > relatively to other mechanisms available to Python for accessing > databases (e.g. ADO). You can *make* ADO go faster, but it takes a good > amount of fine tuning and voodoo. Empirically, the ODBC module is simple > to use (love that API!) and capable of being quite efficient. I suspect that most of the database modules can be given quite a hefty dose of go-faster-stripes, and made quicker. Does ODBC work on non-Windows platforms? > To fetch/insert more than one row at a time, are you using the row count > from fetchmany() and/or the arraysize attribute? At the moment you set the cursor.arraysize, then call fetchmany(None). I've got to add code to fetchmany() to change the arraysize - it will end up that curs.arraysize = 10 curs.fetchmany(100) will set curs.arraysize to 100. Doing a repeated fetchmany() with the same number of rows will have the same effect as setting arraysize manually - it won't have to reallocate space internally, so should be faster. Does someone "own" the API, or should I just make changes to the HTML and mail it to the db-sig list? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pgodman@vgi.com Wed Apr 16 07:10:44 1997 From: pgodman@vgi.com (Peter Godman) Date: Wed, 16 Apr 1997 02:10:44 -0400 (EDT) Subject: [PYTHON DB-SIG] TEXT and IMAGE datatypes in sybase ct module Message-ID: Hi Folks. For some time I've been working on a DBAPI-compliant module for Sybase ct-library. ct-library is the more modern of Sybase's API's (the other being db-library). ct-library has the very nice feature that Sybase provides an unsupported linux version of the library free of charge, hence I can work on it in my free time. I have a question regarding my treatment of TEXT and IMAGE types in the module (equivalent, I believe, to Oracle LONG and LONG RAW columns). As I understand the specification, fetching these datatypes should return Python strings, whereas supplying them as a parameter should be done using dbi wrappers or just a string for TEXT. This is fine. However, Sybase has a special interface for getting data into and out of long columns. In essence, if one wishes to insert a long value into a long column, one must first fetch the CS_IODESC structure (similar to a file descriptor) using a SELECT statement, and then send data down this channel to fill in the long column. Imagining, then, that a user wishes to add a row to the database, and supplies an input variable corresponding to a TEXT column. In order to fulfill this request, the sybase module would have to add the row, somehow figure out how to fetch the row again (which can't be done if there's no primary key (there are no row ids in Sybase)), obtain the CS_IODESC, and send the contents of the variable. I believe such an interface would be very difficult to implement (Updates are similarly difficult), and be unclean. This leaves me with two alternatives. I can either provide an optional file-like interface to CS_IODESCs, so that fetching a row with a TEXT or IMAGE can return a file-like object suitable for reading and writing, or I can stipulate that users specify the contents of long columns in-line in the SQL (which limits long contents to 100K (maximum query length)). I would prefer the former. From what I know of Postgres, it seems it may be appropriate there also. For the file solution I'm imagining something like >>> cursor.execute('SELECT phone, description FROM phones') >>> result = cursor.fetchone() >>> print result ['5551212', ] >>> print result[1].read() This is the description >>> result[1].write('information') Does anyone have any thoughts on this? Do the other databases' APIs not have this limitation? While I'm asking questions, I should also mention that in Sybase, there are lots of behaviours one may configure on a per-connection basis. For example, one may specify whether COMMIT/ROLLBACK closes open cursors, and specify which ANSI isolation level the connection is operating in. I'd like to include support for these options, but from the spec don't see a portable way of doing it. Anyone have any suggestions about this? I could imagine something like >>> import ctsybase >>> connection = ctsybase.ctsybase() >>> connection.options['CLOSE_CURSOR_ON_XACT'] = 1 >>> connection.options['ISOLATION_LEVEL'] = 3 >>> connection.options['FOO'] = 1 SybaseError: 'FOO' is not a valid option for connection >>> print connection.options.keys() ['CLOSE_CURSOR_ON_XACT', 'MAX_COMMANDS', 'MAX_TEXTLEN', 'ISOLATION_LEVEL'] Thanks in advance for any ideas, suggestions, etc. Peter Godman pjg@vgi.com _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Apr 16 11:05:41 1997 From: gstein@microsoft.com (Greg Stein) Date: Wed, 16 Apr 1997 03:05:41 -0700 Subject: [PYTHON DB-SIG] Python Database API Message-ID: <41135C785691CF11B73B00805FD4D2D70277BBE8@RED-17-MSG.dns.microsoft.com> I don't know of any implementation of callproc(). I believe minor changes to the ODBC module (if they're even needed) would support stored procedures via execute(). I believe the same for Informix. I'm not familiar enough with the Oracle one whether it could be done (I do believe we did it with ODBC and Informix, however). DBI can be independent. The question is what sort of utility it might have outside of the DBAPI. It's only real purpose is to provide more type information to the database module for binding the values. For example, a python string can be a VARCHAR or a LONG RAW... Oracle *requires* that it be bound appropriately... the only way to provide that type info is with something like the DBI wrapper. We went through a number of options that would be a bit more declarative, but it made the API overly complex and tossed them; the DBI approach seemed easiest and straight-forward. However, since they are merely wrappers for typeinfo provision, they don't lend much utility outside of the DBAPI. The ODBC modules does work outside of Windows. I recall a post or two to the main Python list with patches and/or info of what needed to be done to make it work under Unix. I seem to recall that the SOLID module is a derivation of the ODBC module. I'm the HTML keeper, the list members are the owners of the API. Feel free to email the HTML to the list and I'll get it uploaded (along with some other changes that I need to do). Thx, -g -----Original Message----- From: Anthony Baxter [SMTP:arb@connect.com.au] Sent: Tuesday, April 15, 1997 10:47 PM To: Greg Stein Cc: 'Mona E. Gamboa'; db-sig@python.org Subject: Re: [PYTHON DB-SIG] Python Database API >>> Greg Stein wrote > Hmm. I thought there was a spec for DBI (just checked... there is, but > it doesn't cover the "generic" exceptions). Personally, I have no I will document what I've done, and add it in. I'd _like_ to see dbi become a seperate module, so we can share the code across all who use it. I'm just not sure how independant it can be. > I would say that any cursors associated with a closed connection become > unusable. Closing cursors should not have an impact on the connection. Yep. This should go into the API. > I've never dealt with callproc. In truth, I'm not positive that it is > needed after all. It seems to be quite possible to simply use execute() > for store procedures in addition to (SQL) statements. Ok, well, is _anyone_ using it? If not, can we drop it from the API? > One interesting note: the ODBC module is apparently quite fast > relatively to other mechanisms available to Python for accessing > databases (e.g. ADO). You can *make* ADO go faster, but it takes a good > amount of fine tuning and voodoo. Empirically, the ODBC module is simple > to use (love that API!) and capable of being quite efficient. I suspect that most of the database modules can be given quite a hefty dose of go-faster-stripes, and made quicker. Does ODBC work on non-Windows platforms? > To fetch/insert more than one row at a time, are you using the row count > from fetchmany() and/or the arraysize attribute? At the moment you set the cursor.arraysize, then call fetchmany(None). I've got to add code to fetchmany() to change the arraysize - it will end up that curs.arraysize = 10 curs.fetchmany(100) will set curs.arraysize to 100. Doing a repeated fetchmany() with the same number of rows will have the same effect as setting arraysize manually - it won't have to reallocate space internally, so should be faster. Does someone "own" the API, or should I just make changes to the HTML and mail it to the db-sig list? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Wed Apr 16 11:43:27 1997 From: gstein@microsoft.com (Greg Stein) Date: Wed, 16 Apr 1997 03:43:27 -0700 Subject: [PYTHON DB-SIG] TEXT and IMAGE datatypes in sybase ct module Message-ID: <41135C785691CF11B73B00805FD4D2D70277BBE9@RED-17-MSG.dns.microsoft.com> Oracle has a similar problem: you must bind the column appropriately. This means that you must know before binding whether you'll bind as a regular string (against, say, a VARCHAR column) or as a LONG (RAW) column. Oracle does allow you, however, to bind the LONG value directly for an insert/update. Note: the existing modules return LONG columns (and their equivalents) in dbiRaw instances. resultcolumn.value contains a Python string with the actual data. Handling of large blobs has been the trickiest part of any of the DBAPI modules. Given the unique constraints of Sybase (this hasn't been seen so far), then I think your solution sounds "best." In other words, move the problem back to the application. The DBAPI isn't meant to make clients of it truly portable across all databases. That simply can't be done. There are too many differences in SQL text, bindings, capabilities, restrictions, etc. Instead, it is meant to provide a uniform method of interaction across the databases to as great an extent as possible. An application that requires more portability can code that at the Python level given their data handling requirements and the set of target databases. This policy is close to that of Python's policy towards C APIs: expose it and do no more. We actually do more, but we can't do it all. Long and short: I think you should be fine with your suggested approach. Regarding the options: simply make them attributes of the connection or cursor (whichever is appropriate), rather than dealing with an option dictionary. Again, a client will know it is dealing with the Sybase module and that those attributes will be present. Whatever options that you *do* add, though, it would be nice to reflect those in the DBAPI spec itself. We can label them all as Sybase specific, but other module maintainers might see a handy parallel with their modules and we could move some of the attributes towards commonality. Having them doc'd, whether specific or not, will be a great boon. -g -----Original Message----- From: Peter Godman [SMTP:pgodman@vgi.com] Sent: Tuesday, April 15, 1997 11:11 PM To: db-sig@python.org Subject: [PYTHON DB-SIG] TEXT and IMAGE datatypes in sybase ct module Hi Folks. For some time I've been working on a DBAPI-compliant module for Sybase ct-library. ct-library is the more modern of Sybase's API's (the other being db-library). ct-library has the very nice feature that Sybase provides an unsupported linux version of the library free of charge, hence I can work on it in my free time. I have a question regarding my treatment of TEXT and IMAGE types in the module (equivalent, I believe, to Oracle LONG and LONG RAW columns). As I understand the specification, fetching these datatypes should return Python strings, whereas supplying them as a parameter should be done using dbi wrappers or just a string for TEXT. This is fine. However, Sybase has a special interface for getting data into and out of long columns. In essence, if one wishes to insert a long value into a long column, one must first fetch the CS_IODESC structure (similar to a file descriptor) using a SELECT statement, and then send data down this channel to fill in the long column. Imagining, then, that a user wishes to add a row to the database, and supplies an input variable corresponding to a TEXT column. In order to fulfill this request, the sybase module would have to add the row, somehow figure out how to fetch the row again (which can't be done if there's no primary key (there are no row ids in Sybase)), obtain the CS_IODESC, and send the contents of the variable. I believe such an interface would be very difficult to implement (Updates are similarly difficult), and be unclean. This leaves me with two alternatives. I can either provide an optional file-like interface to CS_IODESCs, so that fetching a row with a TEXT or IMAGE can return a file-like object suitable for reading and writing, or I can stipulate that users specify the contents of long columns in-line in the SQL (which limits long contents to 100K (maximum query length)). I would prefer the former. From what I know of Postgres, it seems it may be appropriate there also. For the file solution I'm imagining something like >>> cursor.execute('SELECT phone, description FROM phones') >>> result = cursor.fetchone() >>> print result ['5551212', ] >>> print result[1].read() This is the description >>> result[1].write('information') Does anyone have any thoughts on this? Do the other databases' APIs not have this limitation? While I'm asking questions, I should also mention that in Sybase, there are lots of behaviours one may configure on a per-connection basis. For example, one may specify whether COMMIT/ROLLBACK closes open cursors, and specify which ANSI isolation level the connection is operating in. I'd like to include support for these options, but from the spec don't see a portable way of doing it. Anyone have any suggestions about this? I could imagine something like >>> import ctsybase >>> connection = ctsybase.ctsybase() >>> connection.options['CLOSE_CURSOR_ON_XACT'] = 1 >>> connection.options['ISOLATION_LEVEL'] = 3 >>> connection.options['FOO'] = 1 SybaseError: 'FOO' is not a valid option for connection >>> print connection.options.keys() ['CLOSE_CURSOR_ON_XACT', 'MAX_COMMANDS', 'MAX_TEXTLEN', 'ISOLATION_LEVEL'] Thanks in advance for any ideas, suggestions, etc. Peter Godman pjg@vgi.com _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From arw@dante.mh.lucent.com Wed Apr 16 12:05:42 1997 From: arw@dante.mh.lucent.com (Aaron Watters) Date: Wed, 16 Apr 1997 07:05:42 -0400 Subject: [PYTHON DB-SIG] Re: ODBC for Pythonwin Message-ID: <199704161104.HAA11538@dante.mh.lucent.com> From: Kelly Kranabetter >I seem to be unable to find any documentation for the ODBC stuff... >Got any pointers to documentation/sample code? While I can't say authoritatively, I think ODBC should follow the general dbapi described under the db-sig section of http://www.python.org. Also look to the pipermail archives of the db-sig and the pythonwin-sig. An example for the oraclemodule may well work with few or no modifications for ODBC (somebody correct me please). I also thought there was an ODBC tutorial or something somewhere, but dunno where. I also note that the ODBC module is not pythonwin specific (ie, it will run under any Win port of python, not just pythonwin, which is Python inside MFC) -- this is nice in case you want to run batch-style operations. (cc'ed to python-list and db-sig). -- Aaron Watters === The NJ wildlife census is extrapolated from road kills. Conclusion: wildlife is thriving. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From MHammond@skippinet.com.au Thu Apr 17 00:19:35 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 17 Apr 1997 09:19:35 +1000 Subject: [PYTHON DB-SIG] Re: ODBC for Pythonwin Message-ID: <199704162319.JAA17422@minotaur.labyrinth.net.au> > While I can't say authoritatively, I think ODBC should follow > the general dbapi described under the db-sig section of > http://www.python.org. Also look to the pipermail archives of > the db-sig and the pythonwin-sig. An example for the oraclemodule > may well work with few or no modifications for ODBC > (somebody correct me please). I also thought there was an > ODBC tutorial or something somewhere, but dunno where. In the style of Python, I think ODBC should expose an ODBC interface, and someone shoud write a dinky ODBCdb.py, which wraps the desired API. Then everyone has the best of both worlds. Unfortunately, people who use ODBC see it almost as an API in its own right, so Im not sure anyone would actually use it (I know that if someone did it for DAO - the COM based database API - I definately _wouldnt_ use it!) Mark. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Holger.Meyer@informatik.uni-rostock.de Fri Apr 18 00:59:45 1997 From: Holger.Meyer@informatik.uni-rostock.de (Holger Meyer) Date: Fri, 18 Apr 1997 01:59:45 +0200 (MET DST) Subject: [PYTHON DB-SIG] FYI: Interface for Ingres6.4 and OpenIngres Message-ID: <199704172359.BAA10047@marathon.informatik.uni-rostock.de> Hello, I'm just finishing my Ingres6.4 module. Things to do: -- since I wasn't aware of the DB-API, I have to rework my class interface (should be done in python, not C) -- documentation -- since we upgraded to OpenIngres recently, I will port the module, and use dynamic cursor declaration So, if anyone is interested in being beta test site, maybe we can join our efforts. Pleace contact me to get a preliminary version of the code. Peace Holger -- Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group hm@guug.de, http://www.informatik.uni-rostock.de/~hme/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Fri Apr 18 02:16:43 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 17 Apr 1997 18:16:43 -0700 Subject: [PYTHON DB-SIG] RE: Looking for examples of oracledb usage Message-ID: <41135C785691CF11B73B00805FD4D2D70277BC49@RED-17-MSG.dns.microsoft.com> The :N syntax uses database facilities for "binding" the parameter values to the SQL statement, while the form you mention is simply altering the SQL statement that gets sent to the database. There are several benefits to using parameter binding: 1) you don't need to worry about escaping string values 2) certain types of values *can't* be specified in the SQL statement (typically, LONG/BLOB/IMAGE.. whatever you want to call it) 3) you can actually achieve higher efficiencies using parameter binding. The standard sequence of operations with a database is: parse the statement, bind parameters, execute the statement, fetch the results. With parameter binding, you can fill in values to the bound memory and re-execute the statement (skipping the parse/bind steps). By altering the SQL string, you have to go through all the steps again. The parse step is surprisingly expensive! You will see the use of "?" in some database interfaces rather than the :N syntax (which comes from Oracle, actually). The :N variety was chosen because binding positionally is quite handy in a variety of contexts. I hope that clears things up! -g -----Original Message----- From: Daniel Larsson [SMTP:Daniel.Larsson@vasteras.mail.telia.com] Sent: Thursday, April 17, 1997 1:17 PM To: python-list@cwi.nl Subject: Re: Looking for examples of oracledb usage Anthony Baxter wrote in article <199704150430.OAA01115@jambu.off.connect.co m.au>... > >something like > >curs.execute("select * from db where blah = :1 and foo = :2",(123,456)) > >works for me. In general, how does this differ from using the standard string formatting, e.g. curs.execute("select * from db where blah = %d and foo = %d" % (123, 456)) (I assume these examples are equivalent, but I'm asking for the general case) >>>> Roy Smith wrote >> I'm looking for example of python code that uses the oracledb module. >> I've got simple stuff working, but havn't yet figured out how to do >> variable binding in an execute call. The documentation says, "Variables >> are specified in a database-specific notation that is based on the index >> in the parameter tuple (position-based rather than name-based)", but I'm >> not quite sure what all that means. > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Fri Apr 18 02:46:37 1997 From: Anthony Baxter (Anthony Baxter) Date: Fri, 18 Apr 1997 11:46:37 +1000 Subject: [PYTHON DB-SIG] Re: Looking for examples of oracledb usage In-Reply-To: Your message of "Thu, 17 Apr 1997 18:16:43 MST." <41135C785691CF11B73B00805FD4D2D70277BC49@RED-17-MSG.dns.microsoft.com> Message-ID: <199704180146.LAA05246@shara.off.connect.com.au> >>> Greg Stein wrote > 1) you don't need to worry about escaping string values > 2) certain types of values *can't* be specified in the SQL > statement (typically, LONG/BLOB/IMAGE.. whatever you want to call it) > 3) you can actually achieve higher efficiencies using parameter > binding. The standard sequence of operations with a database is: parse You can also, in theory, bind a list of parameter tuples, and it will apply the list one tuple at a time. The current oracle db doesnt do this - I've nearly got it working now. > You will see the use of "?" in some database interfaces rather than the > :N syntax (which comes from Oracle, actually). The :N variety was chosen > because binding positionally is quite handy in a variety of contexts. There's also the :keyword syntax, which the DB-SIG API doesn't support... Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From hmp@infoseek.com Mon Apr 21 23:26:14 1997 From: hmp@infoseek.com (Harold Poskanzer) Date: Mon, 21 Apr 1997 15:26:14 -0700 Subject: [PYTHON DB-SIG] RE: Looking for examples of oracledb usage In-Reply-To: Your message of "Thu, 17 Apr 1997 18:16:43 PDT." <41135C785691CF11B73B00805FD4D2D70277BC49@RED-17-MSG.dns.microsoft.com> Message-ID: <199704212226.PAA04737@seesaw.infoseek.com> Would you believe I was wondering what the oracledbmodule bind variable syntax was the night before I got this email? I have one question, though: I assume I can do :0 through :9 easily, but how do I do more than 10 bind variables? -H ===================================================================== Harold Poskanzer Software Engineer Infoseek Corporation hmp@infoseek.com 2620 Augustine Dr #250 Phone: 408/567-2741 Santa Clara, CA 95054 http://www.infoseek.com/ --------------------------------------------------------------------- Proof of Intelligent Life on the Net > The :N syntax uses database facilities for "binding" the parameter > values to the SQL statement, while the form you mention is simply > altering the SQL statement that gets sent to the database. There are > several benefits to using parameter binding: > > 1) you don't need to worry about escaping string values > 2) certain types of values *can't* be specified in the SQL > statement (typically, LONG/BLOB/IMAGE.. whatever you want to call it) > 3) you can actually achieve higher efficiencies using parameter > binding. The standard sequence of operations with a database is: parse > the statement, bind parameters, execute the statement, fetch the > results. With parameter binding, you can fill in values to the bound > memory and re-execute the statement (skipping the parse/bind steps). By > altering the SQL string, you have to go through all the steps again. The > parse step is surprisingly expensive! > > You will see the use of "?" in some database interfaces rather than the > :N syntax (which comes from Oracle, actually). The :N variety was chosen > because binding positionally is quite handy in a variety of contexts. > > I hope that clears things up! > > -g > > -----Original Message----- > From: Daniel Larsson > [SMTP:Daniel.Larsson@vasteras.mail.telia.com] > Sent: Thursday, April 17, 1997 1:17 PM > To: python-list@cwi.nl > Subject: Re: Looking for examples of oracledb usage > > > Anthony Baxter wrote in article > <199704150430.OAA01115@jambu.off.connect.co > m.au>... > > > >something like > > > >curs.execute("select * from db where blah = :1 and foo = > :2",(123,456)) > > > >works for me. > > In general, how does this differ from using the standard string > formatting, > e.g. > > curs.execute("select * from db where blah = %d and foo = %d" % > (123, 456)) > > (I assume these examples are equivalent, but I'm asking for the > general > case) > > >>>> Roy Smith wrote > >> I'm looking for example of python code that uses the oracledb > module. > >> I've got simple stuff working, but havn't yet figured out how > to do > >> variable binding in an execute call. The documentation says, > "Variables > >> are specified in a database-specific notation that is based > on the > index > >> in the parameter tuple (position-based rather than > name-based)", but > I'm > >> not quite sure what all that means. > > > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ -- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Tue Apr 22 02:02:20 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 21 Apr 1997 18:02:20 -0700 Subject: [PYTHON DB-SIG] RE: Looking for examples of oracledb usage Message-ID: <41135C785691CF11B73B00805FD4D2D70277BC8C@RED-17-MSG.dns.microsoft.com> The bind variables are numbered using 1-based values. As I recall, there is no limit to the number of bind variables you may specify, but Jim Fulton would be the expert here for the oracledb module. My advice: try it and see :-) -g -----Original Message----- From: Harold Poskanzer [SMTP:hmp@infoseek.com] Sent: Monday, April 21, 1997 3:26 PM To: db-sig@python.org Subject: Re: [PYTHON DB-SIG] RE: Looking for examples of oracledb usage Would you believe I was wondering what the oracledbmodule bind variable syntax was the night before I got this email? I have one question, though: I assume I can do :0 through :9 easily, but how do I do more than 10 bind variables? -H ===================================================================== Harold Poskanzer Software Engineer Infoseek Corporation hmp@infoseek.com 2620 Augustine Dr #250 Phone: 408/567-2741 Santa Clara, CA 95054 http://www.infoseek.com/ --------------------------------------------------------------------- Proof of Intelligent Life on the Net > The :N syntax uses database facilities for "binding" the parameter > values to the SQL statement, while the form you mention is simply > altering the SQL statement that gets sent to the database. There are > several benefits to using parameter binding: > > 1) you don't need to worry about escaping string values > 2) certain types of values *can't* be specified in the SQL > statement (typically, LONG/BLOB/IMAGE.. whatever you want to call it) > 3) you can actually achieve higher efficiencies using parameter > binding. The standard sequence of operations with a database is: parse > the statement, bind parameters, execute the statement, fetch the > results. With parameter binding, you can fill in values to the bound > memory and re-execute the statement (skipping the parse/bind steps). By > altering the SQL string, you have to go through all the steps again. The > parse step is surprisingly expensive! > > You will see the use of "?" in some database interfaces rather than the > :N syntax (which comes from Oracle, actually). The :N variety was chosen > because binding positionally is quite handy in a variety of contexts. > > I hope that clears things up! > > -g > > -----Original Message----- > From: Daniel Larsson [SMTP:Daniel.Larsson@vasteras.mail.telia.com] > Sent: Thursday, April 17, 1997 1:17 PM > To: python-list@cwi.nl > Subject: Re: Looking for examples of oracledb usage > > Anthony Baxter wrote in article <199704150430.OAA01115@jambu.off.connect.com.au>... > > > >something like > > > >curs.execute("select * from db where blah = :1 and foo = :2",(123,456)) > > > >works for me. > > In general, how does this differ from using the standard string formatting, e.g. > > curs.execute("select * from db where blah = %d and foo = %d" % (123, 456)) > > (I assume these examples are equivalent, but I'm asking for the general > case) > > >>>> Roy Smith wrote > >> I'm looking for example of python code that uses the oracledb module. > >> I've got simple stuff working, but havn't yet figured out how to do > >> variable binding in an execute call. The documentation says, "Variables > >> are specified in a database-specific notation that is based on the index > >> in the parameter tuple (position-based rather than name-based)", but I'm > >> not quite sure what all that means. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Tue Apr 22 04:30:39 1997 From: Anthony Baxter (Anthony Baxter) Date: Tue, 22 Apr 1997 13:30:39 +1000 Subject: [PYTHON DB-SIG] RE: Looking for examples of oracledb usage In-Reply-To: Your message of "Mon, 21 Apr 1997 18:02:20 MST." <41135C785691CF11B73B00805FD4D2D70277BC8C@RED-17-MSG.dns.microsoft.com> Message-ID: <199704220330.NAA20200@jambu.off.connect.com.au> >>> Greg Stein wrote > The bind variables are numbered using 1-based values. As I recall, there > is no limit to the number of bind variables you may specify, but Jim > Fulton would be the expert here for the oracledb module. The OCI docs say the allowable range is 1-255. I can't see how you'd want more than that in a query... The alternate, :name form of the binding syntax is not supported. I'm not sure I want to add it - it would be nice, but hmmmm.... How about if the bind tuple passed is a dictionary of name: value pairs? Or is that too hacky? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From arb@connect.com.au Wed Apr 23 08:39:49 1997 From: arb@connect.com.au (Anthony Baxter) Date: Wed, 23 Apr 1997 17:39:49 +1000 Subject: [PYTHON DB-SIG] more DB-SIG API clarifications... Message-ID: <199704230739.RAA24185@jambu.off.connect.com.au> The docs for fetchmany() say: > Fetch the next set of rows of a query result, returning as a list of > tuples. An empty list is returned when no more rows are available. The > number of rows to fetch is specified by the parameter. If it is None, > the cursor's arraysize determines the number of rows to be fetched. I'd like to make the following changes: The second sentence should be changed to something like: A list that is shorter than the requested number of rows, or empty, indicates that no more rows are available to be fetched. (this is how the old, and my new, Oracle module behave and seems reasonable) And a minor nitpick - the last sentence should be: If it is None or omitted, the cursor's arraysize determines the number of rows to be fetched. People happy with this? Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________