From anthony at computronix.com Wed Sep 1 18:27:56 2004 From: anthony at computronix.com (Anthony Tuininga) Date: Wed Sep 1 18:56:52 2004 Subject: [DB-SIG] cx_Oracle 4.1 beta1 Message-ID: <4135F88C.80603@computronix.com> What is cx_Oracle? cx_Oracle is a Python extension module that allows access to Oracle and conforms to the Python database API 2.0 specifications with a few exceptions. Where do I get it? http://starship.python.net/crew/atuining What's new? 1) Added support for Python 2.4. In Python 2.4, the datetime module is used for both binding and fetching of date and timestamp data. In Python 2.3, objects from the datetime module can be bound but the This is internal datetime objects will be returned from queries. 2) Added pickling support for LOB and datetime data. 3) Fully qualified the table name that was missing in an alter table statement in the setup test script as noted by Marc Gehling. 4) Added a section allowing for the setting of the RPATH linker directive in setup.py as requested by Iustin Pop. 5) Added code to raise a programming error exception when an attempt is made to access a LOB locator variable in a subsequent fetch. 6) The username, password and dsn (tnsentry) are stored on the connection object when specified, regardless of whether or not a standard connection takes place. 7) Added additional module level constant called "LOB" as requested by Joseph Canedo. 8) Changed exception type to IntegrityError for constraint violations as requested by Joseph Canedo. 9) If scale and precision are not specified, an attempt is made to return a long integer as requested by Joseph Canedo. 10) Added workaround for Oracle bug which returns an invalid handle when the prepare call fails. Thanks to alantam@hsbc.com for providing the code that demonstrated the problem. 11) The cusor method arravar() will now accept the actual list so that it is not necessary to call cursor.arrayvar() followed immediately by var.setvalue(). 12) Fixed bug where attempts to execute the statement "None" with bind variables would cause a segmentation fault. 13) Added support for binding by position (paramstyle = "numeric"). 14) Removed memory leak created by calls to OCIParamGet() which were not mirrored by calls to OCIDescriptorFree(). Thanks to Mihai Ibanescu for pointing this out and providing a patch. 15) Added support for calling cursor.executemany() with statement None implying that the previously prepared statement ought to be executed. Thanks to Mihai Ibanescu for providing a patch. 16) Added support for rebinding variables when a subsequent call to cursor.executemany() uses a different number of rows. Thanks to Mihai Ibanescu for supplying a patch. 17) The microseconds are now displayed in datetime variables when nonzero similar to method used in the datetime module. 18) Added support for binary_float and binary_double columns in Oracle 10g. -- 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 miked at dewhirst.com.au Thu Sep 2 01:06:11 2004 From: miked at dewhirst.com.au (Mike Dewhirst) Date: Thu Sep 2 00:58:28 2004 Subject: [DB-SIG] Re: module name In-Reply-To: <20040901100003.B6CDB1E400A@bag.python.org> References: <20040901100003.B6CDB1E400A@bag.python.org> Message-ID: <6.1.1.1.2.20040902085839.02229ec0@mail.dewhirst.com.au> Could you maybe post the module description in 50 words or less? Mike From randall at tnr.cc Thu Sep 2 06:14:48 2004 From: randall at tnr.cc (Randall Smith) Date: Thu Sep 2 06:14:57 2004 Subject: [DB-SIG] Re: module name In-Reply-To: <6.1.1.1.2.20040902085839.02229ec0@mail.dewhirst.com.au> References: <20040901100003.B6CDB1E400A@bag.python.org> <6.1.1.1.2.20040902085839.02229ec0@mail.dewhirst.com.au> Message-ID: <41369E38.9080403@tnr.cc> Mike, Too late. We went with dal with dbapi as a subpackage. To summarize the previous 50 posts on the subject, we're making an abstraction layer to hide differences in modules that implement dbapi2. It is a wrapper. It also adds uniform datetime objects and switchable paramstyles. The wrapper is the first piece of a larger project, hence it is a sub-package. Although, you will only have to import dal to use it. dal will contain a function that returns a wrapped driver. Here is an example: import dal dbmod = dal.wrapdriver('psycopg') cn = dbmod.connect(database='mydb') cs = cn.cursor() params = dbmod.Date(2004, 1, 1) query = "select * from foo where goo > ?" cs.execute(query, params) result = cs.fetchall() A few things to note. Even though psycopg uses mx.DateTime, the Python datetime.date type was used. dbmod.Date(2004, 1, 1) generated a Python datetime.date object that was translated into an mx.Datetime.DateTimeType during cs.execute(). Also note that I used the 'qmark' paramstyle even though psycopg uses 'pyformat'. Those are the defaults, although both are configurable. Randall Mike Dewhirst wrote: > Could you maybe post the module description in 50 words or less? > > Mike > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From stuart at stuartbishop.net Tue Sep 7 18:29:31 2004 From: stuart at stuartbishop.net (Stuart Bishop) Date: Thu Sep 9 08:16:56 2004 Subject: [DB-SIG] db module wrapper In-Reply-To: <4126662F.6020405@tnr.cc> References: <4123BA93.1040604@tnr.cc> <4123EE84.1080608@colorstudy.com> <41258165.2040006@tnr.cc> <9826f38004081922306be78eac@mail.gmail.com> <41259169.3080209@colorstudy.com> <41264EC9.8090403@tnr.cc> <41265174.3060502@colorstudy.com> <41265670.9060504@tnr.cc> <4126578D.5060902@colorstudy.com> <4126662F.6020405@tnr.cc> Message-ID: <189E325A-00EB-11D9-8381-000A95A06FC6@stuartbishop.net> On 21/08/2004, at 6:59 AM, Randall Smith wrote: > On a separate topic, got any ideas on how to abstract exceptions? If > someone has already figured out an easy way to do this, I sure would > appreciate the knowledge. Present them on the connection or cursor object: con = dball.connect('whatever') cur = con.cursor() try: cur.execute('SOLECT * FROM BAR') except cur.DatabaseError: print 'Oops' Manipulating the base classes of the exception should also work, since Exceptions are still old-style classes. -- Stuart Bishop http://www.stuartbishop.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/db-sig/attachments/20040908/1e563802/PGP.pgp From jacobs at theopalgroup.com Thu Sep 9 13:41:33 2004 From: jacobs at theopalgroup.com (Kevin Jacobs) Date: Thu Sep 9 13:41:37 2004 Subject: [DB-SIG] db module wrapper In-Reply-To: <189E325A-00EB-11D9-8381-000A95A06FC6@stuartbishop.net> References: <4123BA93.1040604@tnr.cc> <4123EE84.1080608@colorstudy.com> <41258165.2040006@tnr.cc> <9826f38004081922306be78eac@mail.gmail.com> <41259169.3080209@colorstudy.com> <41264EC9.8090403@tnr.cc> <41265174.3060502@colorstudy.com> <41265670.9060504@tnr.cc> <4126578D.5060902@colorstudy.com> <4126662F.6020405@tnr.cc> <189E325A-00EB-11D9-8381-000A95A06FC6@stuartbishop.net> Message-ID: <4140416D.70209@theopalgroup.com> Stuart Bishop wrote: > On 21/08/2004, at 6:59 AM, Randall Smith wrote: > >> On a separate topic, got any ideas on how to abstract exceptions? If >> someone has already figured out an easy way to do this, I sure would >> appreciate the knowledge. > > [...] > Present them on the connection or cursor object: > > Manipulating the base classes of the exception should also work, > since Exceptions are still old-style classes. Since Python 2.3, you have been able to modify base classes of new-style objects as well. -Kevin From str_kbs at sancharnet.in Sat Sep 11 05:33:26 2004 From: str_kbs at sancharnet.in (General Electronics,Phaltan) Date: Sat Sep 11 05:20:44 2004 Subject: [DB-SIG] Re: DB-SIG Digest, Vol 17, Issue 12 References: <20040819100002.A74AB1E4017@bag.python.org> Message-ID: <005101c497b0$1b0b9a40$e162013d@h5e1d0> Hi, here is short code which i am using. from mx.ODBC.Windows import * import Image #This is PIL Image Library For Python db = DriverConnect('DSN=ImageData;UID="";PWD=""') #Connect To ODBC db.setconnectoption(SQL.AUTOCOMMIT,SQL.AUTOCOMMIT_ON) #Now Load Image From JPG file img = Image.open("myimg.jpg") #Image Object bx = (0,0,56,57) #Box Object eimg = img.crop(bx) #Image Cropped estrng = eimg.tostring() #Image String This is somewhat 9000 bytes long mylen = len(estrng) #Length Of Image string #Now ODBC DSN is Visual FoxPro Database and Table is imgdata (user defined) #file structure for the imgdata is as follows - # Field Type Length #SRL_NO Numeric 6 #IMG_STN General #Where I want to store estrng mycursor = db.cursor() #Create Cursor to operate SQL mycursor.executedirect('insert into imgdata (SRL_NO,IMG_STN) Value (?,?) ',(SR,estrng)) #Now Read Info From database mycursor.executedirect('select * from imgdata') #Read SQL dta = mycursor.fetchone() #Prepare Dataset ex_estrng = dta[1] #IMG_STN Field Stores Data here if mylen == len(ex_estrng): print "Good" else: print "Bad" #This is what i am getting db.close() Please help me how can I make definatly store data as is in IMG_STN and retrive as Is. Thanks Arvind Sidhaye ----- Original Message ----- From: To: Sent: Thursday, August 19, 2004 3:30 PM Subject: DB-SIG Digest, Vol 17, Issue 12 > Send DB-SIG mailing list submissions to > db-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/db-sig > or, via email, send a message with subject or body 'help' to > db-sig-request@python.org > > You can reach the person managing the list at > db-sig-owner@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DB-SIG digest..." > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. RE: MS SQL Server and odbc getting 'None' > (Carey David SSgt 109CF/SCBJ) > 2. db module wrapper (Randall Smith) > 3. Re: db module wrapper (Ian Bicking) > From stuart at stuartbishop.net Wed Sep 15 07:34:06 2004 From: stuart at stuartbishop.net (Stuart Bishop) Date: Fri Sep 17 22:22:17 2004 Subject: [DB-SIG] Re: db module wrapper In-Reply-To: <412B5CB7.8050203@tnr.cc> References: <412801B7.401@neurokode.com> <412810AD.4010609@tnr.cc> <412819A8.2050901@neurokode.com> <412B1A89.30902@egenix.com> <412B5CB7.8050203@tnr.cc> Message-ID: On 25/08/2004, at 1:20 AM, Randall Smith wrote: > M.-A. Lemburg wrote: >> Jonathan M. Franz wrote: >>> Note to Marc: the clarifications as to the descriptor fields and >>> their meanings we discussed on the python list a long time ago was a >>> big help - but those clarifications are still outstanding in the >>> spec itself. Should I submit a doc patch? >> Yes, please. >>>> I'm mainly programming to API 2. Config files are used to adapt >>>> modules that do not completely comply. In theory, a module that is >>>> API2 compliant needs no config. >>> >>> >>> We're pretty much at the same point. A word of warning - watch out >>> for assumed behaviors. For example, some modules return the number >>> of rows affected by an execute as the return value of the execute; >>> Others do not. The standard just states that return values are >>> undefined - hence the ambiguity and different behavior. >> It says "Return values are not defined". You should use .rowcount to >> access the number of affected rows. The reason is that getting this >> information from the database can be an expensive operation; hence >> you don't want to do this for every single call to .execute(). > Unless someone suggests otherwise, the wrapper's execute method will > return None. If you haven't already, you may want to use the DB-API 2.0 test suite at http://zen.freezope.org/Software/DBAPI20TestSuite/ . It should happily tell you when your code is broken or when the drivers are. I think there is definitely a need for your work - it is the sort of thing a lot of us have wanted to do, but never gotten around to actually doing. Your limited scope (Just DB-API 2.0) is excellent - a project that can actually be completed and used as a foundation for wackier projects. There is also some support to get this sort of thing into Python core (if for no other reason than to counter the false idea that "Python doesn't do databases" which many people get after seeing no reference to them in the reference manual). I'm happy enough to help out if you need extra hands - give me a ping if you set up a dev mailing list or sourceforge project. -- Stuart Bishop http://www.stuartbishop.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/db-sig/attachments/20040915/613c996f/PGP.pgp From stuart at stuartbishop.net Wed Sep 15 07:34:06 2004 From: stuart at stuartbishop.net (Stuart Bishop) Date: Mon Sep 20 10:42:26 2004 Subject: [DB-SIG] Re: db module wrapper Message-ID: On 25/08/2004, at 1:20 AM, Randall Smith wrote: > M.-A. Lemburg wrote: >> Jonathan M. Franz wrote: >>> Note to Marc: the clarifications as to the descriptor fields and >>> their meanings we discussed on the python list a long time ago was a >>> big help - but those clarifications are still outstanding in the >>> spec itself. Should I submit a doc patch? >> Yes, please. >>>> I'm mainly programming to API 2. Config files are used to adapt >>>> modules that do not completely comply. In theory, a module that is >>>> API2 compliant needs no config. >>> >>> >>> We're pretty much at the same point. A word of warning - watch out >>> for assumed behaviors. For example, some modules return the number >>> of rows affected by an execute as the return value of the execute; >>> Others do not. The standard just states that return values are >>> undefined - hence the ambiguity and different behavior. >> It says "Return values are not defined". You should use .rowcount to >> access the number of affected rows. The reason is that getting this >> information from the database can be an expensive operation; hence >> you don't want to do this for every single call to .execute(). > Unless someone suggests otherwise, the wrapper's execute method will > return None. If you haven't already, you may want to use the DB-API 2.0 test suite at http://zen.freezope.org/Software/DBAPI20TestSuite/ . It should happily tell you when your code is broken or when the drivers are. I think there is definitely a need for your work - it is the sort of thing a lot of us have wanted to do, but never gotten around to actually doing. Your limited scope (Just DB-API 2.0) is excellent - a project that can actually be completed and used as a foundation for wackier projects. There is also some support to get this sort of thing into Python core (if for no other reason than to counter the false idea that "Python doesn't do databases" which many people get after seeing no reference to them in the reference manual). I'm happy enough to help out if you need extra hands - give me a ping if you set up a dev mailing list or sourceforge project. -- Stuart Bishop http://www.stuartbishop.net/ From randall at tnr.cc Tue Sep 21 08:25:31 2004 From: randall at tnr.cc (Randall Smith) Date: Tue Sep 21 08:25:35 2004 Subject: [DB-SIG] Re: db module wrapper In-Reply-To: References: <412801B7.401@neurokode.com> <412810AD.4010609@tnr.cc> <412819A8.2050901@neurokode.com> <412B1A89.30902@egenix.com> <412B5CB7.8050203@tnr.cc> Message-ID: <414FC95B.9030004@tnr.cc> Thanks for the test suite reference. It should help out allot. We have set up on sourceforge at http://sourceforge.net/projects/pydal/ Our work is in CVS and we have a feeble working implementation. You can download in from cvs. cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/pydal checkout dal We could use some testing and feedback. Thanks. Randall Stuart Bishop wrote: > > On 25/08/2004, at 1:20 AM, Randall Smith wrote: > >> M.-A. Lemburg wrote: >> >>> Jonathan M. Franz wrote: >>> >>>> Note to Marc: the clarifications as to the descriptor fields and >>>> their meanings we discussed on the python list a long time ago was a >>>> big help - but those clarifications are still outstanding in the >>>> spec itself. Should I submit a doc patch? >>> >>> Yes, please. >>> >>>>> I'm mainly programming to API 2. Config files are used to adapt >>>>> modules that do not completely comply. In theory, a module that is >>>>> API2 compliant needs no config. >>>> >>>> >>>> >>>> We're pretty much at the same point. A word of warning - watch out >>>> for assumed behaviors. For example, some modules return the number >>>> of rows affected by an execute as the return value of the execute; >>>> Others do not. The standard just states that return values are >>>> undefined - hence the ambiguity and different behavior. >>> >>> It says "Return values are not defined". You should use .rowcount to >>> access the number of affected rows. The reason is that getting this >>> information from the database can be an expensive operation; hence >>> you don't want to do this for every single call to .execute(). >> >> Unless someone suggests otherwise, the wrapper's execute method will >> return None. > > > If you haven't already, you may want to use the DB-API 2.0 test > suite at http://zen.freezope.org/Software/DBAPI20TestSuite/ . It > should happily tell you when your code is broken or when the > drivers are. > > I think there is definitely a need for your work - it is the sort > of thing a lot of us have wanted to do, but never gotten around to > actually doing. Your limited scope (Just DB-API 2.0) is excellent - > a project that can actually be completed and used as a foundation > for wackier projects. There is also some support to get this sort > of thing into Python core (if for no other reason than to counter > the false idea that "Python doesn't do databases" which many people > get after seeing no reference to them in the reference manual). > > I'm happy enough to help out if you need extra hands - give me a > ping if you set up a dev mailing list or sourceforge project. > > -- Stuart Bishop > http://www.stuartbishop.net/ From ianb at colorstudy.com Wed Sep 22 08:14:03 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Wed Sep 22 08:14:08 2004 Subject: [DB-SIG] ANN: SQLObject 0.6 (and 0.5.3) Message-ID: <4151182B.1000705@colorstudy.com> I've made a long-overdue release of SQLObject 0.6, and a final bug-fix release for the 0.5 series. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://prdownloads.sourceforge.net/sqlobject/SQLObject-0.6.tar.gz?download News and changes: http://sqlobject.org/docs/News.html What's New ========== In 0.5.3: some small bug fixes, and an important fix when iterating over selects in threaded environments. In 0.6: The "SQLObject" module has been renamed "sqlobject". To fetch objects from the database, use MyClass.get(id) (instead of MyClass(id)). To create/insert objects, use MyClass(col=value, ...) (instead of MyClass.new(col=value, ...)). Better support for constraints. Connections given using URLs, like 'mysql://user:pass@localhost/dbname' Optional lazy updates -- SQL UPDATE executed only on demand. For a more complete list, please see the news: http://sqlobject.org/docs/News.html -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org