From berei@wmdata.com Tue Feb 2 11:23:19 1999 From: berei@wmdata.com (Reinhammar, Bertil) Date: Tue, 2 Feb 1999 12:23:19 +0100 Subject: [DB-SIG] Informixdb maintenance Message-ID: <73F6D4DB2A47D2118F9E0008C7A430B602CCC3DB@wmsto3ci1390.wmdata.se> !!! Been notified by Aaron Watters that the issue has come up. Thanks Aaron ! Truly sorry about the mess and any inconvenience. I'm not going to try making excuses, I've handled this poorly. I've browsed some of the traffic on the subject and 1) Anyone feeling called to take over should announce that. 2) There is, to my knowledge, no copyright whatsoever with respect to IV DocEye or myself or any other legal entity that I'm involved with. If there exist any copyright, it originates before my time. 3) The prime reason for handing the torch over is that I have been assigned to new and substantially different tasks, effectively preventing me from any attempt to restart work on informixdb module. We have looked at the possibility of keeping mainenance within the office but couldn't come up with any viable solution. thanks/ Bertil Reinhammar From gstein@lyra.org Tue Feb 2 11:24:16 1999 From: gstein@lyra.org (Greg Stein) Date: Tue, 02 Feb 1999 03:24:16 -0800 Subject: [DB-SIG] Informixdb maintenance References: <73F6D4DB2A47D2118F9E0008C7A430B602CCC3DB@wmsto3ci1390.wmdata.se> Message-ID: <36B6E060.1926D97C@lyra.org> Reinhammar, Bertil wrote: > ... > 2) There is, to my knowledge, no copyright whatsoever with respect to IV > DocEye or myself > or any other legal entity that I'm involved with. If there exist any > copyright, it originates > before my time. I can definitely/authoritatively state that no prior copyright exists. Since Bertil is stating that he (and his associates) does not desire to hold a copyright, then the new maintainer should assume the copyright for the module. Of course, the new copyright holder can license as they choose, but I would request that they retain the current Python-style license that exists on informixdb. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mskow@crosslink.net Wed Feb 3 03:02:33 1999 From: mskow@crosslink.net (Mike Skowronski) Date: Tue, 2 Feb 1999 22:02:33 -0500 (EST) Subject: [DB-SIG] stored procedures Message-ID: Hi, I'm using the odbc module w/ python 1.5.1 to call stored procedures and they work fine except when the procedure (or the return value on a function) has an output value. For example if I have something like: ret = 0 params = [ret, 1, 2] aCursor.execute('{? = call addthem(?,?)}', params) the value of ret would always be 0 even though if i call the same function from C or pl/sql it behaves correctly -- i.e. adding the 2 input parameters for above e.g. any suggestions? Mike From mal@lemburg.com Wed Feb 3 11:35:44 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 03 Feb 1999 12:35:44 +0100 Subject: [DB-SIG] stored procedures References: Message-ID: <36B83490.1D91755F@lemburg.com> Mike Skowronski wrote: > > Hi, > > I'm using the odbc module w/ python 1.5.1 to call stored procedures and > they work fine except when the procedure (or the return value on > a function) has an output value. For example if I have something like: > > ret = 0 > params = [ret, 1, 2] > aCursor.execute('{? = call addthem(?,?)}', params) > > the value of ret would always be 0 even though if i call the same function > from C or pl/sql it behaves correctly -- i.e. adding the 2 input > parameters for above e.g. any suggestions? The current DB-API does not handle output parameters for cursor.execute(). You could try to produce a result set though and use that for output data via the .fetchXXX() methods. I suggested an improvement on this for the next version of the DB-API Spec. a couple of weeks ago, but have gotten next to no response so far. Maybe this message could revive the discussion... """ 2. Stored procedures Basically I want to revisit the discussion. The 1.1 proposal defines this interface: callproc(procname,list_of_parameters) This method is optional since not all databases provide stored procedures. Call a stored database procedure with the given name. The list of parameters must contain one entry for each argument that the procedure expects. The result of the call is returned by modifying the list contents in place. Input parameters are left untouched, output and input/output parameters replaced with the new values. The procedure may also provide a result set as output. This must then be made available through the standard fetch-methods. Is this general enough to fit everybody's needs ? I know that Jim Fulton would rather like an interface which returns a callable type... but it seems overkill to ask module writers to implement this just to be DB API conform. """ [The message I quoted this from has the subject line "[DB-SIG] API Enhancements"] -- Marc-Andre Lemburg Y2000: 331 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From Ted.Horst@wdr.com Wed Feb 3 15:08:25 1999 From: Ted.Horst@wdr.com (Ted Horst) Date: Wed, 3 Feb 99 09:08:25 -0600 Subject: [DB-SIG] stored procedures In-Reply-To: <36B83490.1D91755F@lemburg.com> References: <36B83490.1D91755F@lemburg.com> Message-ID: <9902031508.AA17280@ch1d2833nwk> On Wed, 03 Feb 1999, "M.-A. Lemburg" wrote: > The result of the call is returned by > modifying the list contents in place. The python CORBA spec leaves the inputs alone, and returns a tuple of the out, inout parameters. Don't know that I have a preference one way or the other, but it might be a good idea to be consistent. Ted Horst (not speaking for any Swiss banks) From mal@lemburg.com Wed Feb 3 21:33:54 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 03 Feb 1999 22:33:54 +0100 Subject: [DB-SIG] stored procedures References: <36B83490.1D91755F@lemburg.com> <9902031508.AA17280@ch1d2833nwk> Message-ID: <36B8C0C2.39A8BC50@lemburg.com> Ted Horst wrote: > > On Wed, 03 Feb 1999, "M.-A. Lemburg" wrote: > > The result of the call is returned by > > modifying the list contents in place. > > The python CORBA spec leaves the inputs alone, and returns a tuple of the > out, inout parameters. Don't know that I have a preference one way or the > other, but it might be a good idea to be consistent. The reason for modifying the parameter list in place was simply that some database interface modules might not be able to determine whether a parameter is IN, INOUT or OUT. In that case, the parameter would be left untouched and the application could check the results for validity. An alternative would be returning the result as tuple by copying all input parameters to it as well. The input list would then be left untouched... output = cursor.callproc(procname,input) with list(output) == list(input) for procedures with only input parameters. This approach might be more Pythonesque since it does not manipulate things in place. Dunno ... I think I'll have to implement this first to see where the difficulties are (does anybody have experience with this ?). -- Marc-Andre Lemburg Y2000: 331 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mskow@crosslink.net Wed Feb 3 23:25:25 1999 From: mskow@crosslink.net (Mike Skowronski) Date: Wed, 3 Feb 1999 18:25:25 -0500 (EST) Subject: [DB-SIG] stored procedures In-Reply-To: <36B83490.1D91755F@lemburg.com> Message-ID: thanks for the info. I tried the fetchXXX() stuff and it didn't work -- odbc returned `invalid cursor state' error. I'd like to have output values available in db-api; it's easy enough to implement in the database api's that i'm familiar with, though i'm not sure how making it a requirment, if stored procs are supported, may affect the support of other databases. Mike On Wed, 3 Feb 1999, M.-A. Lemburg wrote: > Mike Skowronski wrote: > > > > Hi, > > > > I'm using the odbc module w/ python 1.5.1 to call stored procedures and > > they work fine except when the procedure (or the return value on > > a function) has an output value. For example if I have something like: > > > > ret = 0 > > params = [ret, 1, 2] > > aCursor.execute('{? = call addthem(?,?)}', params) > > > > the value of ret would always be 0 even though if i call the same function > > from C or pl/sql it behaves correctly -- i.e. adding the 2 input > > parameters for above e.g. any suggestions? > > The current DB-API does not handle output parameters for > cursor.execute(). > You could try to produce a result set though and use that for > output data via the .fetchXXX() methods. > > I suggested an improvement on this for the next version of the DB-API > Spec. a couple of weeks ago, but have gotten next to no response so far. > Maybe this message could revive the discussion... > > """ > 2. Stored procedures > > Basically I want to revisit the discussion. The 1.1 proposal > defines this interface: > > callproc(procname,list_of_parameters) > This method is optional since not all databases > provide stored procedures. > > Call a stored database procedure with the given > name. The list of parameters must contain one > entry for each argument that the procedure > expects. The result of the call is returned by > modifying the list contents in place. Input > parameters are left untouched, output and > input/output parameters replaced with the new > values. > > The procedure may also provide a result set as > output. This must then be made available through > the standard fetch-methods. > > Is this general enough to fit everybody's needs ? I know that > Jim Fulton would rather like an interface which returns a callable > type... but it seems overkill to ask module writers to implement > this just to be DB API conform. > """ > > [The message I quoted this from has the subject line > "[DB-SIG] API Enhancements"] > > -- > Marc-Andre Lemburg Y2000: 331 days left > --------------------------------------------------------------------- > : Python Pages >>> http://starship.skyport.net/~lemburg/ : > --------------------------------------------------------- > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > > From jeff@endeavor.med.nyu.edu Thu Feb 4 17:04:13 1999 From: jeff@endeavor.med.nyu.edu (Jeff Berliner) Date: Thu, 04 Feb 1999 12:04:13 -0500 Subject: [DB-SIG] oracle modules and linux Message-ID: <929253.3127118653@antwerp.med.nyu.edu> Has anyone successfully compiled either the older oracledb module, or the DCOracle module on a linux box? I've got both running fine on my Digitail Unix machine, but I'm having no luck on a machine with RedHat 5.1. It appears that the oracledb module (my preference, since I got lots of code already) is having a problem with Python 1.5.1, since it's Makefile is designed for 1.4. Is there a more recent Makefile? The DCOracle module, along with a bunch of compilation warnings, is doing the standard Oracle "missing library" stuff, and before spending all afternoon with that, figured I'd ask you guys :) Any pointers or hints are appreciated! - Jeff -- Jeff Berliner jeff@popmail.med.nyu.edu Academic Computing, Phone: (212) 263-5744 New York University School of Medicine Fax: (212) 263-8542 From neel@cswv.com Wed Feb 10 16:59:50 1999 From: neel@cswv.com (Neel Krishnaswami) Date: Wed, 10 Feb 1999 11:59:50 -0500 Subject: [DB-SIG] mxODBC Message-ID: <3.0.1.32.19990210115950.006f7f88@emerald.cswv.com> Hi, I've downloaded the mxODBC package (version 1.0.0) and am trying to get a Windows 95 box to talk to an Oracle database using the Windows ODBC manager. However, the precompiled ODBC.Windows package doesn't seem to have the DriverConnect() constructor. That is, it doesn't show up in the list produced by ODBC.Windows.__dict__.keys(), and gives me an AttributeError if if I try to invoke it. I've rooted ODBC directory tree at C:\Program Files\Python\site\ODBC, and "C:\Program Files\site" is in my PYTHONPATH. For comparison, the mxDateTime package is at C:\Program Files\site\DateTime, and it seems to work fine, so I'm pretty sure it's not path problems biting me. Also, when I checked the __version__ string, I found that it is at version 0.9.0. Is DriverConnect() just not compiled into the binary distribution, or am I foolishly missing something? -- Neel Krishnaswami neelk@cswv.com From mal@lemburg.com Thu Feb 11 10:59:10 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 11 Feb 1999 11:59:10 +0100 Subject: [DB-SIG] mxODBC References: <3.0.1.32.19990210115950.006f7f88@emerald.cswv.com> Message-ID: <36C2B7FE.4D49EDE4@lemburg.com> Neel Krishnaswami wrote: > > Hi, > > I've downloaded the mxODBC package (version 1.0.0) and am trying to get a > Windows 95 box to talk to an Oracle database using the Windows ODBC manager. > > However, the precompiled ODBC.Windows package doesn't seem to have the > DriverConnect() constructor. That is, it doesn't show up in the list produced > by ODBC.Windows.__dict__.keys(), and gives me an AttributeError if if I > try to invoke it. > > I've rooted ODBC directory tree at C:\Program Files\Python\site\ODBC, and > "C:\Program Files\site" is in my PYTHONPATH. For comparison, the mxDateTime > package is at C:\Program Files\site\DateTime, and it seems to work fine, > so I'm pretty sure it's not path problems biting me. > > Also, when I checked the __version__ string, I found that it is at version > 0.9.0. Is DriverConnect() just not compiled into the binary distribution, or > am I foolishly missing something? Unfortunately you are right. For DriverConnect() to be available a compile time switch has to be defined and that was probably forgotten by Martin. Since I still don't have a VC compiler (got too many other things spinning), the precompiled versions are always a little behind. I'm currently adding all patches I get from people compiling the module on Windows, so the next release should make this much easier. Version 1.0.1 will be out in a few days. An while we're at it: version 1.0.0 has a known bug that causes fetching LONGVARCHAR columns to fail. The workaround is simple: add -DADABAS_WORKAROUND to the Setup directives and recompile. 1.0.1 will hopefully have this one fixed. -- Marc-Andre Lemburg Y2000: 323 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mat@cythere.com Tue Feb 16 15:42:52 1999 From: mat@cythere.com (Mathieu Guillaume) Date: Tue, 16 Feb 1999 15:42:52 +0000 (UTC) Subject: [DB-SIG] Informix module and Dynamic Server Message-ID: Hi, I'm using IDS 7.3 on Linux, and installed the client SDK and informixdb module on a Solaris machine. I had some problems getting the module to work (needed to link it against libgls), but now that it works, I get the following error when trying to connect to my database: >>> db=informixdb.informixdb("test@seer") Traceback (innermost last): File "", line 1, in ? File "/usr/local/lib/python1.5/informixdb.py", line 20, in __init__ self.conn = _informixdb.informixdb(logon) InformixdbError: Error 25507 performing LOGON: The specified service name or protocol is unknown. My sqlhosts file contains the following line: seer onsoctcp seer informix k=1,r=0,s=0 Anybody knows what the problem is ? Thanks, Mat From mat@cythere.com Wed Feb 17 11:58:15 1999 From: mat@cythere.com (Mathieu Guillaume) Date: Wed, 17 Feb 1999 11:58:15 +0000 (UTC) Subject: [DB-SIG] Informix module and Dynamic Server - solved Message-ID: Ok, in case anyone meets the same problem, here's the solution to the "InformixdbError: Error 25507 performing LOGON: The specified service name or protocol is unknown." error: the Informix Client SDK on Solaris doesn't seem to support a 'onsoctcp' connection type. I replaced it with ontlitcp (transport layer interface) in my sqlhosts file, and everything works fine so far. Mat From watsons@public.szonline.net Mon Feb 22 03:33:28 1999 From: watsons@public.szonline.net (watson li) Date: Mon, 22 Feb 1999 11:33:28 +0800 Subject: [DB-SIG] RE:LOOKING FOR WILLOW BASKETS BUYERS Message-ID: <02c101be5e1c$2cd7fbc0$159b60ca@watsons.szonline.net> This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01BE5E57.2AD01C00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 CHINA SHENZHEN FOREIGN TRADE(GROUP)CORPORATION TEL:0755-8703664 FAX:0755-8702827 EMAIL:watsons@public.szonline.net DEAR SIRS: WE ARE LOOKING FOR IMPORTERS OR WHOLESALERS OF WILLOW BASKETS. =20 OUR CRAFTS BASKETS ARE MADE BY NATIVE SKILLED PEASANTS. =20 NO MIDDLE MAN INVOLVED.LOW PRICE,BUT GOOD QUALITY IS ASSUARED. =20 A LARGE VARIETY OF DIFFERENT DESIGNS CAN BE SELECTED. =20 WE EXPORT TO MANY COUNTRIES AROUND THE WORLD. BEST REGARDS WATSON LI =20 ------=_NextPart_000_00CE_01BE5E57.2AD01C00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
 

 
    = CHINA SHENZHEN=20 FOREIGN TRADE(GROUP)CORPORATION
TEL:0755-8703664     =20 FAX:0755-8702827
EMAIL:watsons@public.sz= online.net
DEAR = SIRS:
WE ARE LOOKING FOR IMPORTERS OR WHOLESALERS OF = WILLOW=20 BASKETS.
 
OUR CRAFTS BASKETS ARE MADE BY NATIVE SKILLED=20 PEASANTS.
 
NO MIDDLE MAN INVOLVED.LOW PRICE,BUT GOOD QUALITY IS = ASSUARED.
 
A LARGE VARIETY OF DIFFERENT DESIGNS CAN BE=20 SELECTED.
 
WE EXPORT TO MANY COUNTRIES AROUND THE = WORLD.
BEST REGARDS
WATSON LI
 
------=_NextPart_000_00CE_01BE5E57.2AD01C00-- From ORENGM@powell.fabrik.com Tue Feb 23 02:48:00 1999 From: ORENGM@powell.fabrik.com (Michel Orengo) Date: Mon, 22 Feb 1999 18:48:00 -0800 Subject: [DB-SIG] dbiRaw Message-ID: I'm really confused with the dbiRaw class. I want to use odbc to get a raw data from one table and insert the same raw data in another table. Does anybody can give me a simple example how to do that, so I can get started? Thanks for your help From Cameron Mellor" Background: I'm toying with Sybase, Python, and ctsybasemodule, and looking at the idea of writing some date- and calendar*-related functions using dbiDates as my "standard" dates. Unfortunately, I'm having problems with arithmetic operations: [cameron@localhost ~]$ python Python 1.5.1 (#16, Feb 12 1999, 20:22:16) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import ctsybase, dbi, time >>> d = dbi.dbiDate(time.time()) >>> d.value 919939624.244 >>> d + 86400 # fails 919939624.244 >>> 86400 + d # also fails 135310552 But wait, there's more!: >>> d * 2 Segmentation fault (core dumped) Eek! OK, what happened? [cameron@localhost ~]$ gdb python core [... startup; some reformatting ...] (gdb) where #0 0x0 in ?? () #1 0x80630dd in PyNumber_Multiply (v=0x80d13a0, w=0x80f4a88) at abstract.c:372 #2 0x8075ac8 in eval_code2 (co=0x80f5f80, globals=0x80c27b8, locals=0x80c27b8, args=0x0, argcount=0, kws=0x0, kwcount=0, [... rest of the stack ...] (gdb) up #1 0x80630dd in PyNumber_Multiply (v=0x80d13a0, w=0x80f4a88) at abstract.c:372 372 x = (*v->ob_type->tp_as_number-> nb_multiply)(v, w); (gdb) print v->ob_type->tp_as_number->nb_multiply $5 = (PyObject *(*)()) 0 Hmmmm. That would probably do it. Being somewhat new to Python, and especially the Python C API, I'm not really sure where to go to find the problem. Any ideas? Should I just go a-steppin' through PyNumber_Coerce and the rest? On a related note, ctsybase doesn't actually seem to be returning dbiDates: if I do a "select getdate()", I get [[[]]]. That's fine(-ish) for smalldatetimes, but I was expecting at least a [[[]]], or better yet, [[[]]]. Is this correct or have I misunderstood DBI completely? (Caveat: this might not be quite right since I have to mail from Windows and can't try this stuff out as I go. Apologies for errors.) On another related note, is anyone thinking about standardising the DBI helper implementations? I've got both ctsybasemodule and DCOracle (tho' it's not much use to me :-/) and the implementations are different (umm, C vs. Python). Is there some fundamental problem with providing a single version and having the DB module translate native format to DBI-standard format? Or is it just inertia? :-) Any help appreciated! TIA, Cam * Not Mayan calendars or anything like that. Just standard "three working days"-type calculations, with a "little language" (hmmm, maybe Python) for defining holidays, weekends, etc. A little something to keep me busy for a while ... From mal@lemburg.com Thu Feb 25 15:33:05 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 25 Feb 1999 16:33:05 +0100 Subject: [DB-SIG] ctsybasemodule problem and dbi question References: <000801be60b6$854d42a0$23ffd4d4@cameron> Message-ID: <36D56D31.8ECDEDF@lemburg.com> Cameron Mellor wrote: > > Background: > > I'm toying with Sybase, Python, and ctsybasemodule, and looking at the idea > of writing some date- and calendar*-related functions using dbiDates as my > "standard" dates. I'd suggest dumping the dbi date/time implementations and using the type from mxDateTime instead. They provide an easy to use C API and work great from inside Python. mxDateTime can be found here: http://starship.skyport.net/~lemburg/mxDateTime.html An application using mxDateTime's C API is here: http://starship.skyport.net/~lemburg/mxODBC.html > On another related note, is anyone thinking about standardising the DBI > helper implementations? I've got both ctsybasemodule and DCOracle (tho' it's > not much use to me :-/) and the implementations are different (umm, C vs. > Python). Is there some fundamental problem with providing a single version > and having the DB module translate native format to DBI-standard format? Or > is it just inertia? :-) I think dbi is not really needed anymore: The only two types I can think of where it has some use are date/time values (use mxDateTime for those) and RAW input values (don't know how important it is to be able to differentiate between plain strings and RAW input -- plain Python strings work just fine for mxODBC in both modes). Other things that are not defined in the DB API Spec's dbi are monetary types. Those might be useful too... as immutable C extension types with C API. -- Marc-Andre Lemburg Y2000: 309 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From tjohnson@akcache.com Sat Feb 27 02:05:07 1999 From: tjohnson@akcache.com (Timothy Johnson) Date: Fri, 26 Feb 1999 17:05:07 -0900 Subject: [DB-SIG] Redifining Python Message-ID: <199902270205.RAA30355@mailhost.akcache.com> I am just now investigating Python. I just had a converastion with a web page designer who DOES NOT design in Perl, but has Perl modules written for her, but then maintains and modifies code. As a "C" programmer, I use pre-processor defines to create templates for processing web page input (CGI program source). These templates are easy to maintain and recompile by a "para-programmer" such as the individual I mention above. Having stated that, here's my question: Can one write a sophisticated application with Python, but provide a simple, maintainable interface to enable ongoing maintainance by a someone of less programming skills? ("Para-programmer"). Just as I do with my C++ programs. And the beauty of this is that it would not have to be run through a compiler. From Cameron Mellor" From: M.-A. Lemburg >I'd suggest dumping the dbi date/time implementations and using >the type from mxDateTime instead. They provide an easy to use >C API and work great from inside Python. > >mxDateTime can be found here: Been there, built that. :-) I'll take a look for my "play" project. The main reason I can see for not using mxDateTime is that I couldn't rely on people having it available. Now if there were a standard way for a package to retrieve packages it depended on ... oh, wrong SIG ... >I think dbi is not really needed anymore: The only two types I can >think of where it has some use are date/time values (use mxDateTime >for those) and RAW input values (don't know how important it is >to be able to differentiate between plain strings and RAW input -- >plain Python strings work just fine for mxODBC in both modes). I thought they were there as placeholders: that is, you knew from the data that it was "special" and needed appropriate handling. Anyway, I'll take a closer look and see what I can find. I may end up using ctsybase anyway (since I'm playing with Sybase at the moment) and I don't really want it dumping core. :-/ >Other things that are not defined in the DB API Spec's dbi are >monetary types. Those might be useful too... as immutable C extension >types with C API. Hmmmm. Abitrary-precision numbers, with exact arithmetic. (Didn't Tim Peters do a version of that recently?!) Might be an interesting way to learn the C API; if I need them, I might actually have a go. Thanks for the help: more news as (if) it happens, Cam From gstein@lyra.org Sun Feb 28 12:16:48 1999 From: gstein@lyra.org (Greg Stein) Date: Sun, 28 Feb 1999 04:16:48 -0800 Subject: [DB-SIG] ctsybasemodule problem and dbi question References: <001601be6311$9273a980$23ffd4d4@cameron> Message-ID: <36D933B0.229F5D4B@lyra.org> Cameron Mellor wrote: > > From: M.-A. Lemburg > >... > >I think dbi is not really needed anymore: The only two types I can > >think of where it has some use are date/time values (use mxDateTime > >for those) and RAW input values (don't know how important it is > >to be able to differentiate between plain strings and RAW input -- > >plain Python strings work just fine for mxODBC in both modes). > > I thought they were there as placeholders: that is, you knew from the data > that it was "special" and needed appropriate handling. Anyway, I'll take a > closer look and see what I can find. I may end up using ctsybase anyway > (since I'm playing with Sybase at the moment) and I don't really want it > dumping core. :-/ The dbiRAW type is mostly for *input* binding rather than output. As I recall, the Oracle database requires you to bind LONG / LONG RAW columns differently than VARCHAR columns. The dbiRAW type allows the execute() method to use the appropriate binding mechanism -- based on the argument being a string or a dbiRAW object. Note: at the time the Oracle code was written, there was no way for the execute() method to figure out the right way to bind the input. Maybe Oracle has provided a way to prepare an INSERT statement, check the implied input types, and then perform the bind. Somehow, I doubt it though. The dbiDATE type exists for a similar reason: there was no way for the DB modules to determine that a particular input was a date. Presuming that a standard type is established for time/date handling (such as mxDateTime), then the DB module can do the input binding properly. A similar situation would arise for money types or other special column types. If the underlying database requires that a column must be bound in a special way for that type, then the DB module must figure that out from the type of the arguments (since it has nowhere else to turn to for the info). Marc: did I see somewhere that Guido might incorporate mxDateTime as a standard module in 1.6 or something like that? Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sun Feb 28 12:49:58 1999 From: gstein@lyra.org (Greg Stein) Date: Sun, 28 Feb 1999 04:49:58 -0800 Subject: [DB-SIG] API Enhancements References: <36A32169.2ECE2BD@lemburg.com> Message-ID: <36D93B76.1143DEE1@lyra.org> M.-A. Lemburg wrote: > > Hi everybody, > > It's been a long time since we've last had some discussion > about a novelation of the API. As you probably remember I have > a proposed spec available at: > > http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html Is it possible to get this document (or a version of it) red-lined so that we can see the differences from the 1.0 document? I can generally see the differences, but it would be better to clarify it. [ I'd be willing to construct the red-lined version if you'd like assistance ] > ... > 1. Threading > > The API spec should make some notes about the scope of thread > safety imposed on the interfaces. Thread safety could be given > at module level (threads all use the same module, but maintain > their own connections), connection level (threads share modules > and connections, cursors are not shared between threads) and > cursor level (threads share module, connections and cursors). > > The last level is probably not feasable, but I think connection > level could be reached. A discussion in the API would be good. I might even say that a module could export an attribute that states which level is supported. For example, I know that many Win32 ODBC drivers are NOT thread-safe at all. You must open a connection per thread. > > 2. Stored procedures > > Basically I want to revisit the discussion. The 1.1 proposal > defines this interface: > > callproc(procname,list_of_parameters) Should be a sequence of params, and probably should be optional. > This method is optional since not all databases > provide stored procedures. > > Call a stored database procedure with the given > name. The list of parameters must contain one > entry for each argument that the procedure > expects. The result of the call is returned by > modifying the list contents in place. Input > parameters are left untouched, output and > input/output parameters replaced with the new > values. This should be clarified that a copy of the params is made, then modified. The wording sounds like the method mucks with the argument value (which it may not be able to do if the argument is a tuple or other sequence). > The procedure may also provide a result set as > output. This must then be made available through > the standard fetch-methods. > > Is this general enough to fit everybody's needs ? I know that Nobody has said "no" yet, so why don't we just say it is and be done with it. It is certainly a step better than the 1.0 spec. > Jim Fulton would rather like an interface which returns a callable > type... but it seems overkill to ask module writers to implement > this just to be DB API conform. The hope is that the modules are easy to code, and then Python stuff is layered on top if more functionality is needed. It is "The Python Way" :-) > 3. A standard catalog interface > > There is often a need to connect to a database without knowing > in advance what tables it contains and how the table columns > are named. > > The API should define a catalog method for this purpose, I'd say "no" and leave that to a Python-level module. In many databases, you can get this information from special tables. Custom APIs are not required. For those databases that require a custom API, then I'd say the module should expose those functions as a module-specific extension. Creating a "unified" API can then be done at the Python level. Few programs, however, require that unified API, so it seems burdensome to impose a unified API upon the module writers. >... > 4. Optional named cursors > > The cursor constructor should be allowed to have an optional > argument for the cursor name. This is useful for UPDATEs. I do not understand the use or operation of this, and how it would benefit an UPDATE. Could you elaborate? ------ META QUESTION: What should the process be for moving to a new rev of the API? Marc has been championing his changes for well over a year now, but closure hasn't been reached. I would recommend a "Last Call" type of approach. Set the date as (say) March 12, receive comments until then, fold in the comments, then issue a "Final Call" for the updated version for March 26. The DBAPI 1.1 would be posted by Monday the 29th. META-META :-) ... is this approach acceptable? If not, then speak up. If nobody has an issue with the approach, then let's assume that we've begun the Last Call phase. thx -g -- Greg Stein, http://www.lyra.org/ From John.Duperon@EMBL-Heidelberg.de Mon Feb 22 10:47:59 1999 From: John.Duperon@EMBL-Heidelberg.de (John Duperon) Date: Mon, 22 Feb 1999 11:47:59 +0100 Subject: [DB-SIG] Creating portable Python database code Message-ID: <36D135DF.ABBEC61B@embl-heidelberg.de> Hello, my colleagues and I will be creating online databases to hold our scientific data. Some of these projects will be more complex than others, and thus we would like to use MySQL for most of them and Oracle where data integrity is essential. With this in mind, we are trying to decide whether to use Perl or Python for connecting our databases to the web. Do you have any idea whether the Python database API is the same for Oracle and MySQL? We'd like to be able to write code that will work with either database, requiring only the change of the database module, as can be done with Perl's DBI. Thanks for your time, John Duperon Max Planck Institute