From gh at ghaering.de Tue Dec 2 14:29:20 2003 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Tue Dec 2 14:29:26 2003 Subject: [DB-SIG] db_row questions Message-ID: <3FCCE810.3010407@ghaering.de> I've a few questions about db_row: Is there any reason why db_row doesn't allow column access via attributes of the row, but only via the mapping protocol? I'd like to integrate db_row into PySQLite eventually, replacing the PgResultSet stuff I borrowed from pyPgSQL. And to be compatible with PgResultSet I'd need the ability to access columns as attributes of the rows. Do you have any problems with me integrating db_row into PySQLite? Do you think it's worth to rewrite the Python code in db_row in C in order to gain additional performance? Or have you benchmarked it and seen it's not worth it? Thanks for your time, -- Gerhard From jacobs at penguin.theopalgroup.com Tue Dec 2 16:08:25 2003 From: jacobs at penguin.theopalgroup.com (Kevin Jacobs) Date: Tue Dec 2 16:08:31 2003 Subject: [DB-SIG] db_row questions In-Reply-To: <3FCCE810.3010407@ghaering.de> Message-ID: On Tue, 2 Dec 2003, Gerhard H?ring wrote: > I've a few questions about db_row: I'm happy to answer them. In fact, I was just looking into PySQLite today and was quite interested in getting that running. > Is there any reason why db_row doesn't allow column access via attributes of the > row, but only via the mapping protocol? Yes -- one of the primary design criteria for db_row was for compliance with the DB-API 2.0 specification, by emulating the tuple interface as closely as possible and the dict interface where it did not conflict with tuple semantics. For this reason, I could not overload the row object's namespace with methods that may conflict with column names. Thus, the row object contains a fields object, which provides no regular methods, so the only conflicts can occur with column names beginning and ending with '__'. If this is not your preference, PySQLite can return fields objects directly, which support mapping, sequence, and attribute access, at the expense of not having any methods. > I'd like to integrate db_row into PySQLite eventually, replacing the PgResultSet > stuff I borrowed from pyPgSQL. And to be compatible with PgResultSet I'd need the > ability to access columns as attributes of the rows. > > Do you have any problems with me integrating db_row into PySQLite? Sounds like a great idea and I'm happy to provide whatever help you need to make it happen. I do have a few minor updates that have yet to be released, so we should definitely coordinate our efforts to ensure that your releases will have the most recent code. > Do you think it's worth to rewrite the Python code in db_row in C in order to gain > additional performance? Or have you benchmarked it and seen it's not worth it? You may want to look again at the db_row tar or zip archives. They both contain the pure-Python version along with an optional C extension module. With the C module, db_rows are almost as fast as native tuples and dicts for most operations. Best regards, -Kevin Jacobs -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (440) 871-6725 x 19 E-mail: jacobs@theopalgroup.com Fax: (440) 871-6722 WWW: http://www.theopalgroup.com/ From rmangaliag at slu.edu.ph Wed Dec 3 02:08:46 2003 From: rmangaliag at slu.edu.ph (ali) Date: Wed Dec 3 02:03:58 2003 Subject: [DB-SIG] python vs php5 Message-ID: <000c01c3b96c$4c142120$da19a8c0@slu.edu.ph> i've heard that php5 will include declaration of attributes which are private, public and protected... aside from that interfaces which will be implemented by a class can also be created... in line with OO principles, wouldnt these features be good if implemented in python??? ali... :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031203/86829b07/attachment.html From mal at egenix.com Wed Dec 3 04:07:18 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Dec 3 04:07:31 2003 Subject: [DB-SIG] python vs php5 In-Reply-To: <000c01c3b96c$4c142120$da19a8c0@slu.edu.ph> References: <000c01c3b96c$4c142120$da19a8c0@slu.edu.ph> Message-ID: <3FCDA7C6.6040205@egenix.com> ali wrote: > i've heard that php5 will include declaration of attributes which are private, > public and protected... aside from that interfaces which will be implemented by > a class can also be created... > > in line with OO principles, wouldnt these features be good if implemented in > python??? I don't see the reference to databases which is what this list is all about. Please post such messages to comp.lang.python. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Dec 03 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 Kaya.M at gmx.de Thu Dec 4 06:24:38 2003 From: Kaya.M at gmx.de (Mustafa Kaya) Date: Thu Dec 4 06:24:42 2003 Subject: [DB-SIG] Selam... Message-ID: <23219.1070537078@www66.gmx.net> Merhaba Sibel, mesajini okudum...ben 26 yasinda delidolu genc bir erkegim...senin istedigin gibi, seni memnun ederim...yanliz biraz mesafe var aramizda, ben g?ney almanyadan geliyorum...ama sayet birg?n g?neye dogru gelirsen, mutlaka bi kacamak yap! :-) veya ben oraya dogru yolum d?serse...Asil nerde kaliyorsun almanyada?? Selamlar Kara oglan! -- +++ GMX - die erste Adresse f?r Mail, Message, More +++ Neu: Preissenkung f?r MMS und FreeMMS! http://www.gmx.net From brands at ausi.com Fri Dec 5 04:02:07 2003 From: brands at ausi.com (Brands) Date: Fri Dec 5 04:08:30 2003 Subject: [DB-SIG] Attention! Your account (db-sig@python.org) will be deleted in 26 hours. In-Reply-To: <322FB05K88A63HJH@python.org> References: <322FB05K88A63HJH@python.org> Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031205/1ad51c57/attachment.html From martha at msn.com Sat Dec 6 15:13:22 2003 From: martha at msn.com (Jean Rhoades) Date: Sat Dec 6 01:17:51 2003 Subject: [DB-SIG] \Stop the aging process xckl zffefclieja Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031206/a9b1c7bc/attachment.html From martha at msn.com Sat Dec 6 10:35:49 2003 From: martha at msn.com (Lynn Fletcher) Date: Sat Dec 6 01:38:19 2003 Subject: [DB-SIG] .Glowing Skin krqlcwq Message-ID: <1$d02z--n$-52-iku$s-f-56091@3g4p0hdsu> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031206/3174be59/attachment.html From holly at msn.com Tue Dec 9 04:32:15 2003 From: holly at msn.com (Jonathan Nance) Date: Mon Dec 8 12:40:48 2003 Subject: [DB-SIG] Girls just want to have fun, , , , or is it, , , xxess ktiqcgzeh jjtpi f Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031209/76badcfe/attachment.html From galoclean at t-online.de Tue Dec 9 18:52:00 2003 From: galoclean at t-online.de (Ali-Remzi Tatli - eMail galoclena@t-online.de) Date: Tue Dec 9 18:52:22 2003 Subject: [DB-SIG] tanismak Message-ID: <1ATreA-2FYav20@fwd05.sul.t-online.com> merhaba, tanismak istiyorum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031209/445afc7c/attachment.html From harri.pasanen at trema.com Wed Dec 10 07:03:29 2003 From: harri.pasanen at trema.com (Harri Pasanen) Date: Wed Dec 10 07:03:34 2003 Subject: [DB-SIG] How to call function with cursor in-out parameter type? Message-ID: <200312101303.29827.harri.pasanen@trema.com> Hello, I'm a bit at loss how to make the following type of a call from Python DB API, cx_Oracle in this case: SQL> desc myfunc FUNCTION myfunc RETURNS NUMBER Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- PID VARCHAR2 IN DEFAULT CR1 REF CURSOR IN/OUT SQL> var crs refcursor SQL> var ret number SQL> exec :ret := myfunc('YVESX',:crs) SQL> print crs ID LIMIT_ID ... So on return crs is a cursor containing a result set. My initial idea was to do v = cursor.var(cx_Oracle.CURSOR) res = cursor.callfunc("myfunc", cx_Oracle.NUMBER, v) but that does not work, I'm getting "cx_Oracle.NotSupportedError: Variable_TypeByPythonType(): unhandled data type" Any hints on how to go about this? Harri From anthony at computronix.com Wed Dec 10 09:50:56 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Wed Dec 10 09:51:04 2003 Subject: [DB-SIG] How to call function with cursor in-out parameter type? In-Reply-To: <200312101303.29827.harri.pasanen@trema.com> References: <200312101303.29827.harri.pasanen@trema.com> Message-ID: <1071067856.7531.5.camel@chl0122.edmonton.computronix.com> Its actually easier than what you are trying to do... :-) cursorToBind = connection.cursor() result = cursor.callfunc("myfunc", cx_Oracle.NUMBER, (1, cursorToBind)) print "The result is:", result print "The result set is:" for row in cursorToBind: print "Row:", row In other words, create a cursor and then simply bind it where you want it. If you have difficulty making this work, let me know. On Wed, 2003-12-10 at 05:03, Harri Pasanen wrote: > Hello, > > I'm a bit at loss how to make the following type of a call from Python > DB API, cx_Oracle in this case: > > SQL> desc myfunc > FUNCTION myfunc RETURNS NUMBER > Argument Name Type In/Out > Default? > ------------------------------ ----------------------- ------ > -------- > PID VARCHAR2 IN DEFAULT > CR1 REF CURSOR IN/OUT > > SQL> var crs refcursor > SQL> var ret number > SQL> exec :ret := myfunc('YVESX',:crs) > > SQL> print crs > > ID LIMIT_ID > ... > > So on return crs is a cursor containing a result set. > > My initial idea was to do > > v = cursor.var(cx_Oracle.CURSOR) > res = cursor.callfunc("myfunc", cx_Oracle.NUMBER, v) > > but that does not work, I'm getting > > "cx_Oracle.NotSupportedError: Variable_TypeByPythonType(): unhandled > data type" > > Any hints on how to go about this? > > Harri > > > > > > _______________________________________________ > 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 harri.pasanen at trema.com Wed Dec 10 10:47:58 2003 From: harri.pasanen at trema.com (Harri Pasanen) Date: Wed Dec 10 10:48:02 2003 Subject: [DB-SIG] How to call function with cursor in-out parameter type? In-Reply-To: <1071067856.7531.5.camel@chl0122.edmonton.computronix.com> References: <200312101303.29827.harri.pasanen@trema.com> <1071067856.7531.5.camel@chl0122.edmonton.computronix.com> Message-ID: <200312101647.58377.harri.pasanen@trema.com> Thanks for the quick reply, seems to work fine. Now that I have your attention, next question ;-) I have a bunch of Oracle functions with signature FUNCTION foo RETURNS NUMBER arg1 type1 in default (typically = null) arg2 type2 in default (typically = null) . . . argN typeN in default (typically = null) cr1 ref cursor in/out So most arguments can be omitted. The documentation does not mention dictionary style arguments in the context of callproc/callfunction? Do I have other options than to dig out the metadata for the function and build the parameter list from that, if I want to write a generic python function that is capable of calling these functions, without the need to fill in the default arguments? Thanks, Harri On Wednesday 10 December 2003 15:50, Anthony Tuininga wrote: > Its actually easier than what you are trying to do... :-) > > cursorToBind = connection.cursor() > result = cursor.callfunc("myfunc", cx_Oracle.NUMBER, (1, > cursorToBind)) print "The result is:", result > print "The result set is:" > for row in cursorToBind: > print "Row:", row > > In other words, create a cursor and then simply bind it where you > want it. If you have difficulty making this work, let me know. > > On Wed, 2003-12-10 at 05:03, Harri Pasanen wrote: > > Hello, > > > > I'm a bit at loss how to make the following type of a call from > > Python DB API, cx_Oracle in this case: > > > > SQL> desc myfunc > > FUNCTION myfunc RETURNS NUMBER > > Argument Name Type In/Out > > Default? > > ------------------------------ ----------------------- ------ > > -------- > > PID VARCHAR2 IN > > DEFAULT CR1 REF CURSOR > > IN/OUT > > > > SQL> var crs refcursor > > SQL> var ret number > > SQL> exec :ret := myfunc('YVESX',:crs) > > > > SQL> print crs > > > > ID LIMIT_ID > > ... > > > > So on return crs is a cursor containing a result set. > > > > My initial idea was to do > > > > v = cursor.var(cx_Oracle.CURSOR) > > res = cursor.callfunc("myfunc", cx_Oracle.NUMBER, v) > > > > but that does not work, I'm getting > > > > "cx_Oracle.NotSupportedError: Variable_TypeByPythonType(): > > unhandled data type" > > > > Any hints on how to go about this? > > > > Harri > > > > > > > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig From lilo at msn.com Wed Dec 10 20:44:47 2003 From: lilo at msn.com (Eugene Banks) Date: Wed Dec 10 10:55:19 2003 Subject: [DB-SIG] You want to hear her say"she can't get enough of you"? goiphkwxil ds Message-ID: <6$7$-$9cvn$yr-c6ms@4np1yjb5nw> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031211/79486b92/attachment.html From anthony at computronix.com Wed Dec 10 10:56:41 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Wed Dec 10 10:56:47 2003 Subject: [DB-SIG] How to call function with cursor in-out parameter type? In-Reply-To: <200312101647.58377.harri.pasanen@trema.com> References: <200312101303.29827.harri.pasanen@trema.com> <1071067856.7531.5.camel@chl0122.edmonton.computronix.com> <200312101647.58377.harri.pasanen@trema.com> Message-ID: <1071071800.7531.14.camel@chl0122.edmonton.computronix.com> On Wed, 2003-12-10 at 08:47, Harri Pasanen wrote: > Thanks for the quick reply, seems to work fine. You're welcome. > Now that I have your attention, next question ;-) Of course. :-) > I have a bunch of Oracle functions with signature > > FUNCTION foo RETURNS NUMBER > arg1 type1 in default (typically = null) > arg2 type2 in default (typically = null) > . > . > . > argN typeN in default (typically = null) > cr1 ref cursor in/out > > So most arguments can be omitted. > > The documentation does not mention dictionary style arguments in the > context of callproc/callfunction? Do I have other options than to > dig out the metadata for the function and build the parameter list > from that, if I want to write a generic python function that is > capable of calling these functions, without the need to fill in the > default arguments? You can't do so by calling cursor.callfunc() or cursor.callproc() since these by definition require a list (see the DB API spec). That said, there is no reason that cx_Oracle could not do so as an extension to the DB API. I'll keep that in mind for some future release. Just as a side note, most times default parameters are used, they are placed at the end so that they can safely be ignored in most cases. Putting a required parameter at the end requires named parameter passing -- but that's a matter of style that is up to you, not me. :-) In the meantime, however, you can quite easily "roll your own" so to speak with an anonymous PL/SQL block. Specifically, something like this: retValVar = cursor.var(cx_Oracle.NUMBER) cursor.execute(""" begin :retval := foo(arg5 => :arg5, arg6 => :arg6, cr1 => :cur); end;""", arg5 = 1, arg6 = "Another parameter", cr1 = cursorToBind, retval = retValVar) print "Result is:", retValVar.getvalue() ... Hope that helps. > Thanks, > > Harri > > On Wednesday 10 December 2003 15:50, Anthony Tuininga wrote: > > Its actually easier than what you are trying to do... :-) > > > > cursorToBind = connection.cursor() > > result = cursor.callfunc("myfunc", cx_Oracle.NUMBER, (1, > > cursorToBind)) print "The result is:", result > > print "The result set is:" > > for row in cursorToBind: > > print "Row:", row > > > > In other words, create a cursor and then simply bind it where you > > want it. If you have difficulty making this work, let me know. > > > > On Wed, 2003-12-10 at 05:03, Harri Pasanen wrote: > > > Hello, > > > > > > I'm a bit at loss how to make the following type of a call from > > > Python DB API, cx_Oracle in this case: > > > > > > SQL> desc myfunc > > > FUNCTION myfunc RETURNS NUMBER > > > Argument Name Type In/Out > > > Default? > > > ------------------------------ ----------------------- ------ > > > -------- > > > PID VARCHAR2 IN > > > DEFAULT CR1 REF CURSOR > > > IN/OUT > > > > > > SQL> var crs refcursor > > > SQL> var ret number > > > SQL> exec :ret := myfunc('YVESX',:crs) > > > > > > SQL> print crs > > > > > > ID LIMIT_ID > > > ... > > > > > > So on return crs is a cursor containing a result set. > > > > > > My initial idea was to do > > > > > > v = cursor.var(cx_Oracle.CURSOR) > > > res = cursor.callfunc("myfunc", cx_Oracle.NUMBER, v) > > > > > > but that does not work, I'm getting > > > > > > "cx_Oracle.NotSupportedError: Variable_TypeByPythonType(): > > > unhandled data type" > > > > > > Any hints on how to go about this? > > > > > > Harri > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 msanchez at grupoburke.com Wed Dec 10 11:06:04 2003 From: msanchez at grupoburke.com (=?ISO-8859-1?Q?Marcos_S=E1nchez_Provencio?=) Date: Wed Dec 10 11:05:40 2003 Subject: [DB-SIG] Spam, spam, spam and eggs Message-ID: <3FD7446C.6040900@grupoburke.com> ?Is it possible to get rid of the icomming spam to this list? I volunteer to moderate it, if it is necessary. From mal at egenix.com Wed Dec 10 11:11:17 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Dec 10 11:12:58 2003 Subject: [DB-SIG] Spam, spam, spam and eggs In-Reply-To: <3FD7446C.6040900@grupoburke.com> References: <3FD7446C.6040900@grupoburke.com> Message-ID: <3FD745A5.6080108@egenix.com> Marcos S?nchez Provencio wrote: > ?Is it possible to get rid of the icomming spam to this list? I > volunteer to moderate it, if it is necessary. No need. You can use the X-Spam-Status: OK (lists-python 0.000) header to filter out most of the spam. The same is true for most other python.org mailing lists. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 10 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From davidsch at verity.com Wed Dec 10 13:25:01 2003 From: davidsch at verity.com (David Schnepper) Date: Wed Dec 10 13:25:15 2003 Subject: [DB-SIG] Spam, spam, spam and eggs In-Reply-To: <3FD745A5.6080108@egenix.com> Message-ID: How does the header get set? And what does it mean? > -----Original Message----- > From: db-sig-bounces@python.org [mailto:db-sig-bounces@python.org]On > Behalf Of M.-A. Lemburg > Sent: Wednesday, December 10, 2003 8:11 AM > To: Marcos S?nchez Provencio > Cc: Python Database SIG > Subject: Re: [DB-SIG] Spam, spam, spam and eggs > > > Marcos S?nchez Provencio wrote: > > ?Is it possible to get rid of the icomming spam to this list? I > > volunteer to moderate it, if it is necessary. > > No need. You can use the > > X-Spam-Status: OK (lists-python 0.000) > > header to filter out most of the spam. The same is true for most > other python.org mailing lists. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Dec 10 2003) > >>> Python/Zope Consulting and Support ... http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From mal at egenix.com Wed Dec 10 13:39:43 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Dec 10 13:39:49 2003 Subject: [DB-SIG] Spam, spam, spam and eggs In-Reply-To: References: Message-ID: <3FD7686F.8050300@egenix.com> David Schnepper wrote: > How does the header get set? And what does it mean? You'll have to ask that on the meta-sig mailing list. I suppose that spambayes or spamassasin are used to add the header. >>X-Spam-Status: OK (lists-python 0.000) Here's a header of a recent spam message sent to this list: X-Spam-Status: UNSURE (tutor 0.493, default 0.889, personal 0.787, lists-mailman 0.978, public 0.997, lists-python 0.978) and another one: X-Spam-Status: UNSURE (personal 0.760, lists-mailman 0.998, lists-python 0.999) The multiple items seem to originate from the fact that these messages are CCed to multiple recipients/lists. Filtering on lists-python looks like a good way to get started. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 10 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From andy47 at halfcooked.com Thu Dec 11 08:36:48 2003 From: andy47 at halfcooked.com (Andy Todd) Date: Thu Dec 11 08:40:34 2003 Subject: [DB-SIG] Re: Unable to acquire Oracle environment handle In-Reply-To: <620E8C0551A9314BADF5393BC6DFE10D0ADEB3@cernxchg14.cern.ch> References: <620E8C0551A9314BADF5393BC6DFE10D0ADEB3@cernxchg14.cern.ch> Message-ID: <3FD872F0.3000904@halfcooked.com> Lana Abadie wrote: > > Hello, > I had this problem. > When using sqlplus, I can login to the database and I can make queries. > But in this program it doesn't run. I have included the script. It would > be very nice if you can help me. > Best regards, Lana Lana, You will get better, and quicker, responses by mailing the Python DB-SIG mailing list, who I have copied on this response. When asking questions like this it is best to reduce the problem to the smallest possible example which causes the error, and to include the error you are receiving. Preferably a couple of lines which anyone reading the message can copy and paste into a Python interpreter to see your problem. Without some mention of what error or exception your are getting when you run your code I'm afraid I can be of little help. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From anthony at computronix.com Thu Dec 11 09:42:17 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Thu Dec 11 09:42:27 2003 Subject: [DB-SIG] Re: Unable to acquire Oracle environment handle In-Reply-To: <3FD872F0.3000904@halfcooked.com> References: <620E8C0551A9314BADF5393BC6DFE10D0ADEB3@cernxchg14.cern.ch> <3FD872F0.3000904@halfcooked.com> Message-ID: <1071153737.10609.1.camel@chl0122.edmonton.computronix.com> I have seen this error before but, as already stated, without the actual exception and the lines causing the exception its hard to say for sure. That said, when this has happened, the ORACLE_HOME and PATH (Windows) or LD_LIBRARY_PATH (Unix/Linux) are mismatched. That is, the ORACLE_HOME environment variable points to an Oracle 8i installation but the PATH/LD_LIBRARY_PATH variables point to an Oracle 9i installation, for example. Oracle doesn't seem to like this much... :-) On Thu, 2003-12-11 at 06:36, Andy Todd wrote: > Lana Abadie wrote: > > > > Hello, > > I had this problem. > > When using sqlplus, I can login to the database and I can make queries. > > But in this program it doesn't run. I have included the script. It would > > be very nice if you can help me. > > Best regards, Lana > > Lana, > > You will get better, and quicker, responses by mailing the Python DB-SIG > mailing list, who I have copied on this response. > > When asking questions like this it is best to reduce the problem to the > smallest possible example which causes the error, and to include the > error you are receiving. Preferably a couple of lines which anyone > reading the message can copy and paste into a Python interpreter to see > your problem. > > Without some mention of what error or exception your are getting when > you run your code I'm afraid I can be of little help. > > Regards, > Andy -- 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 randyw at pld.com Sat Dec 13 11:08:52 2003 From: randyw at pld.com (R M Wunderlich in Kansas) Date: Sat Dec 13 12:03:59 2003 Subject: [DB-SIG] Thanks, but no thanks Message-ID: We have taken several months to make this decision. We are joining Stephen Smith (Excel Telecom to $1.5 billion faster than Microsoft) and Steve Gurasich (Chairman of GSD&M, a billion $ powerhouse). This is the company that Bill Fields, the former Wal Mart CEO was involved with initially. If you have us on any automatic mailing programs, etc., please remove these addresses from your system: nothurtin@yahoo.com, randyw@pld.com and propel@pld.com. To communicate with me PERSONALLY, please continue to use propel@pld.com, BUT PLEASE STOP THE AUTORESPONDERS. We have puta lot of time and research into this decision. If you want more informa- tion on this company, our shortcut URL is www.passthechicken.com . Feel free to investigate us. You will not be hammered with daily emails. Thanks from Randy From cadfred at oddpost.com Sun Dec 14 06:33:32 2003 From: cadfred at oddpost.com (cadfred@oddpost.com) Date: Sun Dec 14 06:33:38 2003 Subject: [DB-SIG] db-sig Message-ID: EMAL: BGMCRPFOFLOESUHC -------------- next part -------------- A non-text attachment was scrubbed... Name: picture007a.GIF Type: image/gif Size: 4675 bytes Desc: not available Url : http://mail.python.org/pipermail/db-sig/attachments/20031214/d0eb15e6/picture007a.gif From jimiy at msn.com Tue Dec 16 10:19:44 2003 From: jimiy at msn.com (Lynn Ramirez) Date: Tue Dec 16 14:22:42 2003 Subject: [DB-SIG] Impress the daylights out of her! mvngderc gwj Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031216/17e86f18/attachment.html From anthony at computronix.com Wed Dec 17 12:09:24 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Wed Dec 17 12:09:33 2003 Subject: [DB-SIG] cx_Oracle 4.0 Message-ID: <1071680963.3117.5.camel@chl0122.edmonton.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 http://www.computronix.com/utilities.shtml (it may be a few days before the second site is updated) What's new? 1) Added support for subclassing connections, cursors and session pools. The changes involved made it necessary to drop support for Python 2.1 and earlier although a branch exists in CVS to allow for support of Python 2.1 and earlier if needed. 2) Connections and session pools can now be created with keyword parameters, not just sequential parameters. 3) Queries now return integers whenever possible and long integers if the number will overflow a simple integer. Floats are only returned when it is known that the number is a floating point nubmer or the integer conversion fails. 4) Added initial support for user callbacks on OCI functions. See the documentation for more details. 5) Add support for retrieving the bind variable names associated with a cursor with a new method bindnames(). 6) Add support for temporary LOB variables. This means that setinputsizes() can be used with the values CLOB and BLOB to create these temporary LOB variables and allow for the equivalent of empty_clob() and empty_blob() since otherwise Oracle will treat empty strings as NULL values. 7) Automatically switch to long strings when the data size exceeds the maximum string size that Oracle allows (4000 characters) and raise an error if an attempt is made to set a string variable to a size that it does not support. This avoids truncation errors as reported by Jon Franz. 8) Add support for global (distributed) transactions and two phase commit. 9) Force the NLS settings for the session so that test tables are populated correctly in all circumstances; problems were noted by Ralf Braun and Allan Poulsen. 10) Display error messages using the environment handle when the error handle has not yet been created; this provides better error messages during this rather rare situation. 11) Removed memory leak in callproc() that was reported by Todd Whiteman. 12) Make consistent the calls to manipulate memory; otherwise segfaults can occur when the pymalloc option is used, as reported by Matt Hoskins. 13) Force a rollback when a session is released back to the session pool. Apparently the connections are not as stateless as Oracle's documentation suggests and this makes the logic consistent with normal connections. 14) Removed module method attach(). This can be replaced with a call to Connection(handle=) if needed. -- 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 croxton3 at yahoo.com Wed Dec 17 13:16:22 2003 From: croxton3 at yahoo.com (Derek Croxton) Date: Wed Dec 17 13:16:28 2003 Subject: [DB-SIG] Python/PDO field types Message-ID: I've been using PDO successfully, but I can't figure out what the type_id of a field object means. Type_id returns a number that corresponds to a data type, but I can't find any mapping of numbers to types. The help note in PDO says "see the DB-API docs," so I found what I appears to be the correct page at http://www.python.org/peps/pep-0249.html. However, here I can find only a list of types under "Type Objects and Constructors" -- there is no mention of which number corresponds to which type. I figure there must be such a list somewhere (whether part of the Python DB API or of PDO I don't know), so I would appreciate it if someone could direct me to it. Thanks, Derek Croxton From andy47 at halfcooked.com Wed Dec 17 16:10:01 2003 From: andy47 at halfcooked.com (Andy Todd) Date: Wed Dec 17 16:12:11 2003 Subject: [DB-SIG] Python/PDO field types In-Reply-To: References: Message-ID: <3FE0C629.3090104@halfcooked.com> Derek Croxton wrote: > I've been using PDO successfully, but I can't figure out what the > type_id of a field object means. Type_id returns a number that > corresponds to a data type, but I can't find any mapping of numbers to > types. The help note in PDO says "see the DB-API docs," so I found what > I appears to be the correct page at > http://www.python.org/peps/pep-0249.html. However, here I can find only > a list of types under "Type Objects and Constructors" -- there is no > mention of which number corresponds to which type. I figure there must > be such a list somewhere (whether part of the Python DB API or of PDO I > don't know), so I would appreciate it if someone could direct me to it. > > Thanks, > Derek Croxton > As far as I can tell PDO passes on whatever it gets from the cursor description. This is supplied by the underlying DB-API module you use. If its MySQLdb then the answer is in the documentation; """ DATA BINARY = DBAPISet(252, 251, 250, 249) DATE = DBAPISet(10, 14) NULL = 'NULL' NUMBER = DBAPISet(0, 5, 4, 9, 3, 8, 1, 13) ROWID = DBAPISet() STRING = DBAPISet(1, 247, 254, 253) TIME = DBAPISet(11,) TIMESTAMP = DBAPISet(7, 12) """ I got this by typing help("MySQLdb") at the Python prompt (after importing MySQLdb). If you are connecting to a different type of database then look at the documentation for the db module. I'm running MySQL 4.0.16, MySQLdb 0.9.2 and Python 2.3.2 Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From bgudorf at neurokode.com Wed Dec 17 16:31:20 2003 From: bgudorf at neurokode.com (Bryan J Gudorf) Date: Wed Dec 17 16:31:26 2003 Subject: [DB-SIG] Python/PDO field types In-Reply-To: <3FE0C629.3090104@halfcooked.com> Message-ID: Andy, Derek, This is correct. PDO does pass on the type_code it gets from .description. Although these types are specified in the DB-API, you may need to check with your module documentation on how to use them. Bryan J Gudorf ~NeuroKode Labs, LLC -----Original Message----- From: db-sig-bounces@python.org [mailto:db-sig-bounces@python.org]On Behalf Of Andy Todd Sent: Wednesday, December 17, 2003 4:10 PM To: Derek Croxton Cc: db-sig@python.org Subject: Re: [DB-SIG] Python/PDO field types Derek Croxton wrote: > I've been using PDO successfully, but I can't figure out what the > type_id of a field object means. Type_id returns a number that > corresponds to a data type, but I can't find any mapping of numbers to > types. The help note in PDO says "see the DB-API docs," so I found what > I appears to be the correct page at > http://www.python.org/peps/pep-0249.html. However, here I can find only > a list of types under "Type Objects and Constructors" -- there is no > mention of which number corresponds to which type. I figure there must > be such a list somewhere (whether part of the Python DB API or of PDO I > don't know), so I would appreciate it if someone could direct me to it. > > Thanks, > Derek Croxton > As far as I can tell PDO passes on whatever it gets from the cursor description. This is supplied by the underlying DB-API module you use. If its MySQLdb then the answer is in the documentation; """ DATA BINARY = DBAPISet(252, 251, 250, 249) DATE = DBAPISet(10, 14) NULL = 'NULL' NUMBER = DBAPISet(0, 5, 4, 9, 3, 8, 1, 13) ROWID = DBAPISet() STRING = DBAPISet(1, 247, 254, 253) TIME = DBAPISet(11,) TIMESTAMP = DBAPISet(7, 12) """ I got this by typing help("MySQLdb") at the Python prompt (after importing MySQLdb). If you are connecting to a different type of database then look at the documentation for the db module. I'm running MySQL 4.0.16, MySQLdb 0.9.2 and Python 2.3.2 Regards, Andy -- ---------------------------------------------------------------------------- ---- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From andy47 at halfcooked.com Thu Dec 18 05:35:08 2003 From: andy47 at halfcooked.com (Andy Todd) Date: Thu Dec 18 05:38:56 2003 Subject: [DB-SIG] Python/PDO field types In-Reply-To: References: Message-ID: <3FE182DC.6020702@halfcooked.com> Bryan J Gudorf wrote: > Andy, Derek, > This is correct. PDO does pass on the type_code it gets from .description. > Although these types are specified in the DB-API, you may need to check with > your > module documentation on how to use them. > > Bryan J Gudorf > ~NeuroKode Labs, LLC > [snip] Whilst the DB-API specifies that you should have these types, it doesn't specify (probably quite rightly) how you should implement them. Which can be confusing. I think what PDO is doing is correct, but just wanted to point out that what is returned as a column type is down to the DB module and their implementations can vary. For instance, MySQLdb (as previously mentioned) uses the MySQLdb.constants.FIELD_TYPE module to identify the type of columns in a cursor (which are a series of numbers mapped to descriptions). Contrast that with cx_Oracle which has a number of type objects (BINARY, DATETIME, NUMBER, STRING, etc.) which are used to categorise the columns returned from an execute and will be in the description attribute of your cursor. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From anthony at computronix.com Thu Dec 18 13:26:54 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Thu Dec 18 13:27:12 2003 Subject: [DB-SIG] cx_OracleDBATools 2.0 Message-ID: <1071772014.1633.31.camel@chl0122.edmonton.computronix.com> What is it? cx_OracleDBATools is a set of Python scripts that handle Oracle DBA tasks in a cross platform manner. These scripts are intended to work the same way on all platforms and hide the complexities involved in managing Oracle databases, especially on Windows. Binaries are provided for those who do not have a Python installation. Where do I get it? http://starship.python.net/crew/atuining http://www.computronix.com/utilities.shtml utronix.com (it may be a few days before the second site is updated) What's new? 1) Added tool ExortControlFile to create a file containing the statements necessary for recreating a control file. This file is similar to the one created by the statement "alter database backup controlfile to trace" but it allows you to specify the file name and it also modifies the statements output such that recreating the controlfile is possible without any changes. 2) Added tool CloneDB to clone a database. This tool copies all of the files associated with the database and then creates a new control file and starts the cloned database. 3) Added tool BackupDB to perform a cold backup on a database. 4) Added tool RestoreDB to restore a database from a backup performed by the tool BackupDB. This tool can also be used to restore a database with a different SID and different paths so that a backup file can be restored on a different machine so long as the platform and Oracle version remain constant. 5) Added tool RemoveDB to remove a database completely from the machine. 6) Added option --all to StartDB and StopDB to start or stop all databases on the machine. 7) Added option --all-auto to StartDB to start all databases marked as automatic start (similar to the Oracle script dbstart on Unix). 8) Added ability to StartDB and StopDB to start or stop multiple databases at once. 9) Added option --shutdown-mode to StopDB to allow for issuing a shutdown abort, for example. 10) Added option --config-file-name on all tools to allow overriding the configuration file name and also give an indication of where the default configuration file is located. -- 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 anthony at computronix.com Thu Dec 18 17:41:35 2003 From: anthony at computronix.com (Anthony Tuininga) Date: Thu Dec 18 17:41:48 2003 Subject: [DB-SIG] cx_OracleTools 7.2 Message-ID: <1071787295.1633.63.camel@chl0122.edmonton.computronix.com> What is it? cx_OracleTools is a set of Python scripts that handle Oracle database development tasks in a cross platform manner and improve (in my opinion) on the tools that are available by default in an Oracle client installation. Those who use cx_Oracle (a Python interface driver for Oracle compatible with the DB API) may also be interested in this project, if only as examples. Binaries are provided for those who do not have a Python installation. Where do I get it? http://starship.python.net/crew/atuining http://www.computronix.com/utilities.shtml (it may be a few days before the second site is updated) What's new? 1) Added new tools ExportColumn and ImportColumn for exporting (importing) CLOB and BLOB columns from (into) an Oracle database. 2) Include package used for debugging. 3) When using DescribeObject, check if the object with the given name matches an object in the database, including case. If the object cannot be found, check for an object in the database by converting the argument to uppercase. Finally, if the name is not found and is not qualified with a schema owner, search the public synonyms for one by that name and describe that object instead. 4) Added feedback to DbDebugger indicating on what database the connection has been established and on what pipe name the debugger is listening. 5) Added optional argument to specify a filename into which to put the output created by DescribeObject. This is of particular use on Windows which doesn't handle redirection very well, particularly in GUI programs. -- 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 ratanprasad.gupta at teleatlas.com Tue Dec 30 09:17:08 2003 From: ratanprasad.gupta at teleatlas.com (Ratan Prasad Gupta) Date: Tue Dec 30 09:17:20 2003 Subject: [DB-SIG] informix connectivity problem Message-ID: <3FF188E4.7535C569@teleatlas.com> I have already installed this informixdb module into my linux server, but I have one problem after doing following steps to run the cgi script. 1. I make a copy of HTML page which call a mylogin.cgi (on Submit) which validate the username and password. 2. When it is called and executed by the browser ,no page contents are displayed. 3. if i run this cgi with python by "python mylogin.cgi", it connects to the database and displays the table information. but when i run using IE browser it is not showing any result. can u guide me about the bugs in program and configuration. your help is really worth for me. thanks in advance. From msanchez at grupoburke.com Tue Dec 30 14:42:39 2003 From: msanchez at grupoburke.com (=?ISO-8859-1?Q?Marcos_S=E1nchez_Provencio?=) Date: Tue Dec 30 14:42:51 2003 Subject: [DB-SIG] informix connectivity problem In-Reply-To: <3FF188E4.7535C569@teleatlas.com> References: <3FF188E4.7535C569@teleatlas.com> Message-ID: <3FF1D52F.6000705@grupoburke.com> Hello there You must check two things first: * You are sending the right header Content type: text/html or something * You can run the script as the www server user (such as www-data, nobody or whatever), with its permissions and environment. It does not seem a db problem, though... ?Does it show any error message, at the browser or at the server log? Ratan Prasad Gupta wrote: >I have already installed this informixdb module into my linux server, >but I have one problem after doing following steps to run the cgi >script. > >1. I make a copy of HTML page which call a mylogin.cgi (on Submit) which > >validate the username and password. >2. When it is called and executed by the browser ,no page contents are >displayed. >3. if i run this cgi with python by "python mylogin.cgi", it connects to > >the database and displays the table information. > but when i run using IE browser it is not showing any result. > >can u guide me about the bugs in program and configuration. your help is > >really worth for me. > >thanks in advance. > > > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > > From sambhare at cae.wisc.edu Tue Dec 30 15:49:33 2003 From: sambhare at cae.wisc.edu (sambhare@cae.wisc.edu) Date: Tue Dec 30 15:49:40 2003 Subject: [DB-SIG] Using embedded MySQL (libmysqld) in Python Message-ID: <1072817373.3ff1e4dd3a0ba@www.cae.wisc.edu> Hi, Some background first. I'm working on a open source video transcription application, Transana (www.transana.org). Transana is written in Python and has both a multiuser and a single user version. We are currently using MySQL server in the multiuser version, and would ideally like to use the MySQL embedded version in the single user version. We are using the MySQLdb module to connect to MySQL in the multiuser version. Is there any way of using this module to also connect to the embedded version of MySQL? Is it possible to use the ctypes module to load the dynamic library, and use it via the MySQLdb module from that point? Has anybody faced this kind of problem before? Any help would be appreciated. Sincerely, Rajas Sambhare Developer Wisconsin Center for Education Research, Madison, WI From cs1spw at bath.ac.uk Tue Dec 30 16:35:41 2003 From: cs1spw at bath.ac.uk (Simon Willison) Date: Tue Dec 30 16:35:46 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? Message-ID: <3FF1EFAD.8070402@bath.ac.uk> We're trying to find a Python DB module for Postgres that includes native support for 2.3's datetime.py date types - so dates come out of the database as datetime objects and datetime objects are converted to postgres date times on insert/update transparently. We haven't found one yet. Is there any movement within the Python DB community towards 2.3's datetime.py? It seems like a great way of dealing with dates, but the current batch of DB modules all appear to use their own convention. Is this something that the DB API standard should cover? Any tips on how to best deal with the transfer of dates from Python to Postgres and back again would be welcome. Thanks, Simon Willison Web development weblog: http://simon.incutio.com/ From guido at python.org Tue Dec 30 16:41:03 2003 From: guido at python.org (Guido van Rossum) Date: Tue Dec 30 16:38:33 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: Your message of "Tue, 30 Dec 2003 15:35:41 CST." <3FF1EFAD.8070402@bath.ac.uk> References: <3FF1EFAD.8070402@bath.ac.uk> Message-ID: <200312302141.hBULf3R01703@c-24-5-183-134.client.comcast.net> > We're trying to find a Python DB module for Postgres that includes > native support for 2.3's datetime.py date types - so dates come out of > the database as datetime objects and datetime objects are converted to > postgres date times on insert/update transparently. > > We haven't found one yet. Is there any movement within the Python DB > community towards 2.3's datetime.py? It seems like a great way of > dealing with dates, but the current batch of DB modules all appear to > use their own convention. Is this something that the DB API standard > should cover? I guess 2.3 hasn't been out long enough to get the various db api authors to make the switch. Perhaps a DB-API standard update should be issued (e.g. DB-API 2.1) that requires using this for Python 2.3? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at egenix.com Tue Dec 30 16:39:26 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Dec 30 16:39:28 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <3FF1EFAD.8070402@bath.ac.uk> References: <3FF1EFAD.8070402@bath.ac.uk> Message-ID: <3FF1F08E.3080002@egenix.com> Simon Willison wrote: > We're trying to find a Python DB module for Postgres that includes > native support for 2.3's datetime.py date types - so dates come out of > the database as datetime objects and datetime objects are converted to > postgres date times on insert/update transparently. > > We haven't found one yet. Is there any movement within the Python DB > community towards 2.3's datetime.py? It seems like a great way of > dealing with dates, but the current batch of DB modules all appear to > use their own convention. Is this something that the DB API standard > should cover? The standard already supports date/time values and how they can be passed to the database modules. Most DB modules use the mxDateTime extension to deal with this. > Any tips on how to best deal with the transfer of dates from Python to > Postgres and back again would be welcome. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From fog at initd.org Tue Dec 30 16:41:36 2003 From: fog at initd.org (Federico Di Gregorio) Date: Tue Dec 30 16:41:27 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <3FF1EFAD.8070402@bath.ac.uk> References: <3FF1EFAD.8070402@bath.ac.uk> Message-ID: <1072820496.3491.33.camel@localhost> Il mar, 2003-12-30 alle 22:35, Simon Willison ha scritto: > We're trying to find a Python DB module for Postgres that includes > native support for 2.3's datetime.py date types - so dates come out of > the database as datetime objects and datetime objects are converted to > postgres date times on insert/update transparently. psycopg 2 will support it. first betas will be released around 15 january. > Any tips on how to best deal with the transfer of dates from Python to > Postgres and back again would be welcome. right now psycopg allow user code to hook a conversion function into its typecasting machinery. you can ask psycopg "when you encounter a date just call my function and use the result". that means you can have right now 2.3's datetime objects. -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Qu'est ce que la folie? Juste un sentiment de libert? si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata Url : http://mail.python.org/pipermail/db-sig/attachments/20031230/a1eb9a27/attachment.bin From cs1spw at bath.ac.uk Tue Dec 30 16:48:11 2003 From: cs1spw at bath.ac.uk (Simon Willison) Date: Tue Dec 30 16:48:17 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <1072820496.3491.33.camel@localhost> References: <3FF1EFAD.8070402@bath.ac.uk> <1072820496.3491.33.camel@localhost> Message-ID: <3FF1F29B.2090709@bath.ac.uk> Federico Di Gregorio wrote: > right now psycopg allow user code to hook a conversion function into its > typecasting machinery. you can ask psycopg "when you encounter a date > just call my function and use the result". that means you can have right > now 2.3's datetime objects. That sounds ideal - we can use a custom conversion function for the moment and upgrade to psycopg2 in a month or so. Thanks for the tip. From fog at initd.org Tue Dec 30 16:51:49 2003 From: fog at initd.org (Federico Di Gregorio) Date: Tue Dec 30 16:51:30 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <3FF1F29B.2090709@bath.ac.uk> References: <3FF1EFAD.8070402@bath.ac.uk> <1072820496.3491.33.camel@localhost> <3FF1F29B.2090709@bath.ac.uk> Message-ID: <1072821108.3491.37.camel@localhost> Il mar, 2003-12-30 alle 22:48, Simon Willison ha scritto: > Federico Di Gregorio wrote: > > right now psycopg allow user code to hook a conversion function into its > > typecasting machinery. you can ask psycopg "when you encounter a date > > just call my function and use the result". that means you can have right > > now 2.3's datetime objects. > > That sounds ideal - we can use a custom conversion function for the > moment and upgrade to psycopg2 in a month or so. Thanks for the tip. the geotypes package (included in latest psycopg packages or available separately) is a very good example of how to use the new_type and register_type functions. it provides automatic type casting from postgresql geo types to python. -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org La felicit? ? una tazza di cioccolata calda. Sempre. -- Io -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata Url : http://mail.python.org/pipermail/db-sig/attachments/20031230/2e59e774/attachment.bin From davidrushby at yahoo.com Tue Dec 30 16:55:11 2003 From: davidrushby at yahoo.com (David Rushby) Date: Tue Dec 30 16:55:19 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <3FF1EFAD.8070402@bath.ac.uk> Message-ID: <20031230215511.43280.qmail@web11003.mail.yahoo.com> --- Simon Willison wrote: > We haven't found one yet. Is there any movement within the Python DB > community towards 2.3's datetime.py? It seems like a great way of > dealing with dates, but the current batch of DB modules all appear to > use their own convention. Is this something that the DB API standard > should cover? Most of them (AFAIK) use mx.DateTime, which is recommended by the DB API standard as follows: "The preferred object types for the date/time objects are those defined in the mxDateTime package." > Is there any movement within the Python DB community towards 2.3's > datetime.py? kinterbasdb 3.1 (an Interbase/Firebird module) supports both mx.DateTime and stdlib datetime with equal convenience via its dynamic type translation facility, but it defaults to mx.DateTime for backward compatibility. See http://kinterbasdb.sourceforge.net/dist_docs/usage.html#faq_fep_datetime > Is this something that the DB API standard should cover? If the standard is updated to make a definite pronouncement on the date/time representation, how about also specifying a fixed point representation? It seems logical to address both of these ambiguities at the same time. __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 From mal at egenix.com Tue Dec 30 16:58:50 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Dec 30 16:58:51 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <200312302141.hBULf3R01703@c-24-5-183-134.client.comcast.net> References: <3FF1EFAD.8070402@bath.ac.uk> <200312302141.hBULf3R01703@c-24-5-183-134.client.comcast.net> Message-ID: <3FF1F51A.1050104@egenix.com> Guido van Rossum wrote: >>We're trying to find a Python DB module for Postgres that includes >>native support for 2.3's datetime.py date types - so dates come out of >>the database as datetime objects and datetime objects are converted to >>postgres date times on insert/update transparently. >> >>We haven't found one yet. Is there any movement within the Python DB >>community towards 2.3's datetime.py? It seems like a great way of >>dealing with dates, but the current batch of DB modules all appear to >>use their own convention. Is this something that the DB API standard >>should cover? > > I guess 2.3 hasn't been out long enough to get the various db api > authors to make the switch. Perhaps a DB-API standard update should > be issued (e.g. DB-API 2.1) that requires using this for Python 2.3? No, that would not be in the spirit of the DB-API standard. The spec already includes a reference the datetime module, but in its current state it's not too useful for C extensions: http://www.python.org/peps/pep-0249.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From guido at python.org Tue Dec 30 17:05:17 2003 From: guido at python.org (Guido van Rossum) Date: Tue Dec 30 17:02:44 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: Your message of "Tue, 30 Dec 2003 13:55:11 PST." <20031230215511.43280.qmail@web11003.mail.yahoo.com> References: <20031230215511.43280.qmail@web11003.mail.yahoo.com> Message-ID: <200312302205.hBUM5Hk01792@c-24-5-183-134.client.comcast.net> > --- Simon Willison wrote: > > We haven't found one yet. Is there any movement within the Python DB > > community towards 2.3's datetime.py? It seems like a great way of > > dealing with dates, but the current batch of DB modules all appear to > > use their own convention. Is this something that the DB API standard > > should cover? > > Most of them (AFAIK) use mx.DateTime, which is recommended by the DB > API standard as follows: "The preferred object types for the date/time > objects are those defined in the mxDateTime package." That was written years before the 2.3 datetime type existed though. I expect that if the standard were written today, for use with Python 2.3 or later, support of the standard datetime type would be required, in addition to allowing optional support for a user-specified type (the callback sketched earlier in this thread seems a fine mechanism). > > Is this something that the DB API standard should cover? > > If the standard is updated to make a definite pronouncement on the > date/time representation, how about also specifying a fixed point > representation? It seems logical to address both of these ambiguities > at the same time. Why? We have a working datetime type in 2.3. We don't have a fixed-point type anywhere (the Decimal type in the sandbox is decimal *floating* point). --Guido van Rossum (home page: http://www.python.org/~guido/) From guido at python.org Tue Dec 30 17:08:27 2003 From: guido at python.org (Guido van Rossum) Date: Tue Dec 30 17:05:55 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: Your message of "Tue, 30 Dec 2003 22:58:50 +0100." <3FF1F51A.1050104@egenix.com> References: <3FF1EFAD.8070402@bath.ac.uk> <200312302141.hBULf3R01703@c-24-5-183-134.client.comcast.net> <3FF1F51A.1050104@egenix.com> Message-ID: <200312302208.hBUM8RM01815@c-24-5-183-134.client.comcast.net> > > I guess 2.3 hasn't been out long enough to get the various db api > > authors to make the switch. Perhaps a DB-API standard update should > > be issued (e.g. DB-API 2.1) that requires using this for Python 2.3? > > No, that would not be in the spirit of the DB-API standard. Why is standardizing on one universally available type not in the DB-API's spirit? Does the DB-API allow implementers to use non-standard integer or string types? > The spec already includes a reference the datetime module, > but in its current state it's not too useful for C extensions: > > http://www.python.org/peps/pep-0249.html That's a useful criticism. How can this be addressed? I don't know enough about implementing a database adapter to understand the needs from a C extension's perspective. Is it just the need to create a datetime instance from C code efficiently? Can you point me to the docs for the mxDateTime C-level API? --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at egenix.com Tue Dec 30 17:23:24 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Dec 30 17:23:25 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <200312302208.hBUM8RM01815@c-24-5-183-134.client.comcast.net> References: <3FF1EFAD.8070402@bath.ac.uk> <200312302141.hBULf3R01703@c-24-5-183-134.client.comcast.net> <3FF1F51A.1050104@egenix.com> <200312302208.hBUM8RM01815@c-24-5-183-134.client.comcast.net> Message-ID: <3FF1FADC.4000308@egenix.com> Guido van Rossum wrote: >>>I guess 2.3 hasn't been out long enough to get the various db api >>>authors to make the switch. Perhaps a DB-API standard update should >>>be issued (e.g. DB-API 2.1) that requires using this for Python 2.3? >> >>No, that would not be in the spirit of the DB-API standard. > > > Why is standardizing on one universally available type not in the > DB-API's spirit? Does the DB-API allow implementers to use > non-standard integer or string types? The DB-API standard is designed to allow pluralism and defines clear interfaces to support data types that are specific to databases, such as date/time, binaries, blobs, etc. The aim is to make it easy for the module programmers to comply to the specification while at the same time giving users who are looking for cross- database module compatibility a base to build upon. The long history of the DB API specification and the great number of database modules have proven the success of this approach and I don't see any need to change this. Your comparison of date/time values and strings/integers is flawed: dealing with date/time values is not straight forward and each date/time type implementation will put emphasis on different aspects. Also note that the DB API does not enforce usage of the builtin string types or integers. This is on purpose, since module implementors may want to use their own decimal type, or use Unicode objects instead of string objects. The module implementor should have the right to choose and that's what the DB API standard allows him to do. >>The spec already includes a reference the datetime module, >>but in its current state it's not too useful for C extensions: >> >> http://www.python.org/peps/pep-0249.html > > > That's a useful criticism. How can this be addressed? I don't know > enough about implementing a database adapter to understand the needs > from a C extension's perspective. Is it just the need to create a > datetime instance from C code efficiently? Can you point me to the > docs for the mxDateTime C-level API? http://www.egenix.com/files/python/mxDateTime.html#API -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 30 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From davidrushby at yahoo.com Wed Dec 31 03:03:02 2003 From: davidrushby at yahoo.com (David Rushby) Date: Wed Dec 31 03:03:07 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <200312302205.hBUM5Hk01792@c-24-5-183-134.client.comcast.net> Message-ID: <20031231080302.75808.qmail@web11001.mail.yahoo.com> --- Guido van Rossum wrote: >> --- David Rushby wrote: >> Most of them (AFAIK) use mx.DateTime, which is recommended by the DB >> API standard as follows: "The preferred object types for the date/time >> objects are those defined in the mxDateTime package." > >That was written years before the 2.3 datetime type existed though. >I expect that if the standard were written today, for use with Python >2.3 or later, support of the standard datetime type would be required, >in addition to allowing optional support for a user-specified type >(the callback sketched earlier in this thread seems a fine >mechanism). That sounds reasonable to me, but the DB API Spec 2 is *not* being written today; if Spec 2.1 suddenly mandates that dates and times be represented via the datetime module, thousands of client apps will be compatible with Spec 2.0 but not Spec 2.1. A change of this magnitude seems more appropriate for Spec 3.0, just as you're holding off on backward-incompatible changes to Python until 3.0. A scheme such as kinterbasdb 3.1's, in which the previous module-specific date/time representation remains the default (preserving backward-compatibility), but seamless stdlib datetime integration is available, seems more appropriate for a Spec 2.x point revision. >> If the standard is updated to make a definite pronouncement on the >> date/time representation, how about also specifying a fixed point >> representation? It seems logical to address both of these ambiguities >> at the same time. > >Why? We have a working datetime type in 2.3. We don't have a >fixed-point type anywhere (the Decimal type in the sandbox is decimal >*floating* point). As I see it, a backward-incompatible change such as that which you're suggesting should be reserved for a major revision. While making that revision, why not address the numerous other sore points and inconsistencies that DB API users perennially complain about? Otherwise we'll be crossing bump after bump of limited-scope backward-incompatibilities; these are more difficult for maintainers to keep track of than infrequent but broad redefinitions. Most major programming platforms follow the "infrequent but broad redefinition" model when backward incompatibilities are deemed necessary (e.g., Python 2->3, Perl 5->6, Zope 2->3, Apache 1->2, and Win32->.NET). As for the specifics of the Python representation of NUMERIC/DECIMAL database values, my concern is that there be a standard way to move the values to and from the database precisely. Unless I'm missing something, the sandbox Decimal.Decimal type can accomplish this even though it's not fixed-point. What happens in the Python client code when arithmetic is performed on the values is not a database I/O issue. Rounding values bound for storage in the database is, but a DB API driver could perform this operation via the Decimal.Decimal.fixedPoint method, leaving control of the specific rounding algorithm to the client programmer (via the rounding facilities of the Decimal module). __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 From mal at egenix.com Wed Dec 31 08:31:03 2003 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Dec 31 08:31:11 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <20031231080302.75808.qmail@web11001.mail.yahoo.com> References: <20031231080302.75808.qmail@web11001.mail.yahoo.com> Message-ID: <3FF2CF97.5020206@egenix.com> David Rushby wrote: > --- Guido van Rossum wrote: > >>>--- David Rushby wrote: >>>Most of them (AFAIK) use mx.DateTime, which is recommended by the DB >>>API standard as follows: "The preferred object types for the > > date/time > >>>objects are those defined in the mxDateTime package." >> >>That was written years before the 2.3 datetime type existed though. >>I expect that if the standard were written today, for use with Python >>2.3 or later, support of the standard datetime type would be required, >>in addition to allowing optional support for a user-specified type >>(the callback sketched earlier in this thread seems a fine >>mechanism). > > That sounds reasonable to me, but the DB API Spec 2 is *not* being > written today; if Spec 2.1 suddenly mandates that dates and times be > represented via the datetime module, thousands of client apps will be > compatible with Spec 2.0 but not Spec 2.1. A change of this magnitude > seems more appropriate for Spec 3.0, just as you're holding off on > backward-incompatible changes to Python until 3.0. I don't think we need to break anything just to allow datetime types being used in database modules. In fact, the current DB API revision already allows their usage (just as it allows strings to be used for date/time representation or tuples of values). > A scheme such as kinterbasdb 3.1's, in which the previous > module-specific date/time representation remains the default > (preserving backward-compatibility), but seamless stdlib datetime > integration is available, seems more appropriate for a Spec 2.x point > revision. Since Python's type system is becoming more and more flexible, and many database modules already provide one way or another to set type mappings, perhaps we ought to start thinking of a new standard mechanism to setup and define these type mappings ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 31 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jagarenbraperson at yahoo.se Wed Dec 31 09:58:19 2003 From: jagarenbraperson at yahoo.se (=?iso-8859-1?q?Henrik=20Ekelund?=) Date: Wed Dec 31 09:58:24 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py support? In-Reply-To: <3FF1EFAD.8070402@bath.ac.uk> Message-ID: <20031231145819.87347.qmail@web13303.mail.yahoo.com> Adodbapi supports 2.3 datetime types, as well as mxDateTime. In order for it to work with postgres you would have to 1. Use Windows. 2. Find a suitable ODBC or OleDB driver. Henrik Ekelund http://adodbapi.sourceforge.net/ H?strusk och gr? moln - k?p en resa till solen p? Yahoo! Resor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20031231/30f01e79/attachment.html From wnvcole at peppermillcas.com Wed Dec 31 12:14:50 2003 From: wnvcole at peppermillcas.com (Vernon Cole) Date: Wed Dec 31 12:16:04 2003 Subject: [DB-SIG] WHat's the status of DB modules and datetime.py supp ort? Message-ID: <07AF3C77A0FBD311A99F00508B65203903272BB4@sebastian.peppermillcas.com> Thank you, Mark, for suggesting that we define a method for defining type mappings! (You saved me from having to flame you for sounding proprietary about mxDateTime.) Let me for a moment climb up on my soap box and say something about standards: (Lecture mode ON) It has been said that: "Standards are wonderful things, and the best thing about them is that there are so many to choose from!" Let us consider for a moment a standard which failed because the standard makers lacked the courage to make a stand. I refer to RS-422. RS-422 was defined to extend and improve the old RS-232 serial communications interface that we all know and use. The technical improvements of RS-422 over RS-232 are obvious and remarkable. RS-422 is capable of much of the same functionality as USB, and would very likely have become as popular except for one small item. The standards body failed to specify a physical connector for the interface. The electrical interface was defined, but no one knew what shape of plug to attach it to. They could have used a DB-9 or DB-7 connector, or RJ-12 or RJ-45 modular, or invented something new. It would have made little difference. But they did not specify, and manufacturers stayed away in droves. A standard which fails to actually standardize is a leaky lifeboat. (Lecture mode OFF) The dbAPI spec is in danger from this tendency to under-standardize. I quote: * The preferred object types for the date/time objects are those defined in the mxDateTime package. It provides all necessary constructors and methods both at Python and C level. ... * Starting with Python 2.3, module authors can also use the object types defined in the standard datetime module for date/time processing. However, it should be noted that this does not expose a C API like mxDateTime does which means that integration with C based database modules is more difficult. I don't much care whether the updated standard is called 2.1 or 3.0, the point is that the standard is incomplete and needs continued work. Operations which should be simple are not defined. Date encoding and Fixed-point ASCIIdecimal fields have both been mentioned in this thread. Named reference to a column is also missing. I fear I released a hornet's nest of comments on that subject in September. At that time, Jon Franz remarked: " Unfortunately, I think you've fallen victim to some of the hubris present in the SIG. Many of the people here seem perfectly fine with the status quo. Perhaps they worked on DB-API specifications, and thus feel protective of it? ... I think perhaps it has more to do with the attitudes of those involved in the SIG, to be honest. I've watched this list for quite a while, and although helpful, many people seem to shun the idea of providing higher level interfaces in the DB-API, such as access-by-column-name." Let's get busy on that next spec and make a good thing great. ---------- Vernon Cole ................. -----Original Message----- From: M.-A. Lemburg [mailto:mal@egenix.com] Sent: Wednesday, December 31, 2003 6:31 AM To: db-sig@python.org Subject: Re: [DB-SIG] WHat's the status of DB modules and datetime.py support? David Rushby wrote: > --- Guido van Rossum wrote: > >>>--- David Rushby wrote: >>>Most of them (AFAIK) use mx.DateTime, which is recommended by the DB >>>API standard as follows: "The preferred object types for the > > date/time > >>>objects are those defined in the mxDateTime package." >> >>That was written years before the 2.3 datetime type existed though. >>I expect that if the standard were written today, for use with Python >>2.3 or later, support of the standard datetime type would be required, >>in addition to allowing optional support for a user-specified type >>(the callback sketched earlier in this thread seems a fine >>mechanism). > > That sounds reasonable to me, but the DB API Spec 2 is *not* being > written today; if Spec 2.1 suddenly mandates that dates and times be > represented via the datetime module, thousands of client apps will be > compatible with Spec 2.0 but not Spec 2.1. A change of this magnitude > seems more appropriate for Spec 3.0, just as you're holding off on > backward-incompatible changes to Python until 3.0. I don't think we need to break anything just to allow datetime types being used in database modules. In fact, the current DB API revision already allows their usage (just as it allows strings to be used for date/time representation or tuples of values). > A scheme such as kinterbasdb 3.1's, in which the previous > module-specific date/time representation remains the default > (preserving backward-compatibility), but seamless stdlib datetime > integration is available, seems more appropriate for a Spec 2.x point > revision. Since Python's type system is becoming more and more flexible, and many database modules already provide one way or another to set type mappings, perhaps we ought to start thinking of a new standard mechanism to setup and define these type mappings ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 31 2003) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig