From r33007@email.sps.mot.com Fri Jan 15 04:03:01 1999 From: r33007@email.sps.mot.com (Larry Gwinn) Date: Thu, 14 Jan 1999 21:03:01 -0700 Subject: [DB-SIG] oracledb memory leak Message-ID: <369EBDF4.919EC6DA@email.sps.mot.com> Hi All, I am using the oracledb extension on HP-UX 10.20 for an intensive and persistent process and am seeing memory leaks that consumes over 100 Mgs before the process finally crashes. Has anyone seen a memory leak problem with the oracledb extension? Does anyone know if there is a Python database extension that is comparable (i.e similar functionallty, API's) to oracledb that will run on HP-UX, AIX and NT 4.0? Thanks for the help, Larry From arw@ifu.net Fri Jan 15 21:17:41 1999 From: arw@ifu.net (arw@ifu.net) Date: Fri, 15 Jan 1999 21:17:41 -0000 Subject: [DB-SIG] oracledb memory leak In-Reply-To: <369EBDF4.919EC6DA@email.sps.mot.com> Message-ID: <199901162217.RAA01375@python.org> <369ebdf4.919ec6d-@email.sps.mot.com> wrote: Original Article: http://www.egroups.com/list/db-sig/?start=596 > Hi All, > > I am using the oracledb extension on HP-UX 10.20 for an intensive and > persistent process and am seeing memory leaks that consumes over 100 Mgs > > before the process finally crashes. Has anyone seen a memory leak > problem with the oracledb extension? > > Does anyone know if there is a Python database extension that is > comparable (i.e similar functionallty, API's) to oracledb that will run > on HP-UX, AIX and NT 4.0? > > Thanks for the help, > > Larry You didn't specify whether you wanted to stick with Oracle or not. If you do, maybe have a look at the odbc or mxodbc modules. If you don't then please have a look at gadfly (if your database can fit into virtual memory all at once -- gadfly is in-memory, but honestly it's the most portable single sql implementation in existence, speaking as the humble author :) ). -- Aaron Watters http://www.chordate.com === Out of Memory [ Okay ] From mal@lemburg.com Mon Jan 18 11:56:25 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 18 Jan 1999 12:56:25 +0100 Subject: [DB-SIG] API Enhancements Message-ID: <36A32169.2ECE2BD@lemburg.com> 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 The old one ist at: http://www.python.org/sigs/db-sig/DatabaseAPI.html I have some more points that I would like to clarify: 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. 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. 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, returning a sequence of all known objects of a certain type in the database, e.g. tables and views, in a predefined way, e.g. db.catalog('tables') ODBC has a wide variety of such functions, but they all return result sets with different schemas. Therefore I'd suggest having the interface not return a result set, but instead a Python list using a single format for all types of objects (passing None for non applicable or unkown entries): (qualifier,name,type,owner[,optional additional entries]) To find out the column names a function could then use empty SELECTs and the cursor description attribute, e.g. c = db.cursor() c.execute('SELECT * FROM %s WHERE 1=0' % tablename) # look at c.description 4. Optional named cursors The cursor constructor should be allowed to have an optional argument for the cursor name. This is useful for UPDATEs. Comments ? -- Marc-Andre Lemburg Y2000: 347 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From jim.fulton@digicool.com Mon Jan 18 17:42:13 1999 From: jim.fulton@digicool.com (Jim Fulton) Date: Mon, 18 Jan 1999 12:42:13 -0500 Subject: [DB-SIG] oracledb memory leak References: <199901162217.RAA01375@python.org> Message-ID: <36A37275.375B05C7@digicool.com> arw@ifu.net wrote: > > <369ebdf4.919ec6d-@email.sps.mot.com> wrote: > Original Article: http://www.egroups.com/list/db-sig/?start=596 > > Hi All, > > > > I am using the oracledb extension on HP-UX 10.20 for an intensive and > > persistent process and am seeing memory leaks that consumes over 100 Mgs > > > > before the process finally crashes. Has anyone seen a memory leak > > problem with the oracledb extension? > > > > Does anyone know if there is a Python database extension that is > > comparable (i.e similar functionallty, API's) to oracledb that will run > > on HP-UX, AIX and NT 4.0? > > > > Thanks for the help, > > > > Larry > > You didn't specify whether you wanted to stick with Oracle or not. > If you do, maybe have a look at the odbc or mxodbc modules. Oracle's ODBC drivers leak bad. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From adustman@comstar.net Mon Jan 18 17:59:08 1999 From: adustman@comstar.net (Andy Dustman) Date: Mon, 18 Jan 1999 12:59:08 -0500 (EST) Subject: [DB-SIG] API Enhancements In-Reply-To: <36A32169.2ECE2BD@lemburg.com> Message-ID: On Mon, 18 Jan 1999, M.-A. Lemburg wrote: > 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. This, of course, depends on what sort of threading support is built into the database. Part of the reason this question is being asked is because of a little e-mail discussion between me and Marc... Basically, I have a server app where I have wanted to have a threaded server using mxODBC, but I could never use it because I always ran into a memory leak, so I had to switch to a forked model (not a big pain with SocketServer). However, M.-A. has now found the leak so I can think about doing this again with mxODBC. C extensions in Python are basically thread-safe by default, due to the global interpreter lock: While the C extension is running, it has the lock, so no other thread can run. This, by itself, would make a pretty useless threading implementation, so Guido has some macros in the Python API to give up and reacquire the lock around sections of code that would block for arbitrarily long periods of time: Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. Judicious use of this construct makes a C extension module what I call thread-friendly. I guess you can manipulate some Python objects to some extent, but nobody else can be in a position to notice (like modifying tuples: You can do it, as long as nobody else knows it exists yet). I believe that in practice, if the database's client library is thread-safe, then the Python interface module for it needs to be thread-friendly, or else there will be poor performance in threads: Even if each thread has it's own connection, only one can be using the database module at any given time, and database accesses will block all threads for arbitrarily long periods of time. Generally I don't think threads should try to share connections mainly because even if it is thread-safe, it has some very strange implications for transactions. It may mess up client-server protocols as well. So sharing cursors becomes a moot point. BTW, I have developed a patch against MySQLmodule-1.4 which makes it thread-friendly; however, I have not been able to test it very well. Any volunteers. > 4. Optional named cursors > > The cursor constructor should be allowed to have an optional > argument for the cursor name. This is useful for UPDATEs. This is so easy to implement (at least for ODBC) that there's no good reason not to do it. Where it doesn't make sense, the API can just ignore the optional argument. -- Andy Dustman You should always say "spam" and "eggs" ComStar Communications Corp. instead of "foo" and "bar" (706) 549-7689 | PGP KeyID=0xC72F3F1D in Python examples. (Mark Lutz) From mal@lemburg.com Mon Jan 18 19:30:26 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 18 Jan 1999 20:30:26 +0100 Subject: [DB-SIG] API Enhancements References: Message-ID: <36A38BD2.67E09E67@lemburg.com> Andy Dustman wrote: > > On Mon, 18 Jan 1999, M.-A. Lemburg wrote: > > > 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. > > This, of course, depends on what sort of threading support is built into > the database. Part of the reason this question is being asked is because > of a little e-mail discussion between me and Marc... > > Basically, I have a server app where I have wanted to have a threaded > server using mxODBC, but I could never use it because I always ran into a > memory leak, so I had to switch to a forked model (not a big pain with > SocketServer). However, M.-A. has now found the leak so I can think about > doing this again with mxODBC. Actually, I found a different leakage than the one announced on c.l.p. They will both be fixed in the next release which is due later this week. > C extensions in Python are basically thread-safe by default, due to the > global interpreter lock: While the C extension is running, it has the > lock, so no other thread can run. This, by itself, would make a pretty > useless threading implementation, so Guido has some macros in the Python > API to give up and reacquire the lock around sections of code that would > block for arbitrarily long periods of time: Py_BEGIN_ALLOW_THREADS and > Py_END_ALLOW_THREADS. Judicious use of this construct makes a C extension > module what I call thread-friendly. I guess you can manipulate some Python > objects to some extent, but nobody else can be in a position to notice > (like modifying tuples: You can do it, as long as nobody else knows it > exists yet). > > I believe that in practice, if the database's client library is > thread-safe, then the Python interface module for it needs to be > thread-friendly, or else there will be poor performance in threads: Even > if each thread has it's own connection, only one can be using the database > module at any given time, and database accesses will block all threads for > arbitrarily long periods of time. > > Generally I don't think threads should try to share connections mainly > because even if it is thread-safe, it has some very strange implications > for transactions. It may mess up client-server protocols as well. So > sharing cursors becomes a moot point. I've added those thread macros around most long running calls, e.g. those preparing, executing and fetching data and connects, in mxODBC. Since I'm not running threaded applications with it, someone else will have to check whether those macros do no harm to the data integrity of the various supported databases. -- Marc-Andre Lemburg Y2000: 347 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From bigd@europa.com Tue Jan 19 09:09:13 1999 From: bigd@europa.com (Donald A. Daugherty) Date: Tue, 19 Jan 1999 01:09:13 -0800 Subject: [DB-SIG] ODBC VC++ 5 Compilation Message-ID: <000001be438b$621c75a0$cc36cacc@bigd> I get numerous errors from wchar.h and then a whole host of other errors when I try to compile (I downloaded this just today). I followed the instructions to the letter (I am only learning VC++ and my C/C++ experience is limited). Can you shed any light on this? I am downloading the current M$ universal data access SDK, it was the only thing I saw when I went looking for the ODBC SDK. It implies that it includes the ODBC stuff as well. Let me know, I am very interested in getting this compiled. Thanks! Donald A. Daugherty --------------------Configuration: ODBC - Win32 Debug-------------------- Compiling... mxODBC.cpp G:\DevStudio\VC\INCLUDE\wchar.h(820) : error C2733: second C linkage of overloaded function 'wmemchr' not allowed G:\DevStudio\VC\INCLUDE\wchar.h(822) : error C2733: second C linkage of overloaded function 'wcschr' not allowed G:\DevStudio\VC\INCLUDE\wchar.h(824) : error C2733: second C linkage of overloaded function 'wcspbrk' not allowed G:\DevStudio\VC\INCLUDE\wchar.h(826) : error C2733: second C linkage of overloaded function 'wcsrchr' not allowed G:\DevStudio\VC\INCLUDE\wchar.h(828) : error C2733: second C linkage of overloaded function 'wcsstr' not allowed G:\Python\Odbc\Windows\mxODBC.cpp(308) : error C2059: syntax error : '__stdcall' G:\Python\Odbc\Windows\mxODBC.cpp(2251) : error C2664: 'PyDict_GetItemString' : cannot convert parameter 2 from 'unsigned char [10]' to 'char *' G:\Python\Odbc\Windows\mxODBC.cpp(2779) : warning C4273: 'strtod' : inconsistent dll linkage. dllexport assumed. G:\Python\Odbc\Windows\mxODBC.cpp(2795) : warning C4018: '==' : signed/unsigned mismatch G:\Python\Odbc\Windows\mxODBC.cpp(2851) : warning C4018: '==' : signed/unsigned mismatch G:\Python\Odbc\Windows\mxODBC.cpp(3936) : error C2664: 'SQLDescribeCol' : cannot convert parameter 3 from 'char [20]' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4611) : error C2664: 'SQLTables' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4655) : error C2664: 'SQLTablePrivileges' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4700) : error C2664: 'SQLColumns' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4745) : error C2664: 'SQLColumnPrivileges' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4793) : error C2664: 'SQLForeignKeys' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4837) : error C2664: 'SQLPrimaryKeys' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4881) : error C2664: 'SQLProcedures' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4927) : error C2664: 'SQLProcedureColumns' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(4977) : error C2664: 'SQLSpecialColumns' : cannot convert parameter 3 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(5024) : error C2664: 'SQLStatistics' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(5162) : error C2086: 'mxODBCursor_Type' : redefinition G:\Python\Odbc\Windows\mxODBC.cpp(5265) : error C2664: 'SQLConnect' : cannot convert parameter 2 from 'char *' to 'unsigned char *' G:\Python\Odbc\Windows\mxODBC.cpp(5565) : error C2086: 'mxODBC_Type' : redefinition G:\Python\Odbc\Windows\mxODBC.cpp(5797) : error C2070: illegal sizeof operand Error executing cl.exe. ODBC.dll - 22 error(s), 3 warning(s) From vinay@itintegrated.com Mon Jan 18 18:00:17 1999 From: vinay@itintegrated.com (vinay) Date: Mon, 18 Jan 1999 23:00:17 +0500 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #86 - 5 msgs In-Reply-To: <199901191701.MAA13941@python.org> Message-ID: <3.0.5.32.19990118230017.007aa770@itintegrated.com> At 12:01 PM 1/19/99 -0500, you wrote: >Send DB-SIG maillist submissions to > db-sig@python.org > >To subscribe or unsubscribe via the web, visit > http://www.python.org/mailman/listinfo/db-sig >or, via email, send a message with subject or body 'help' to > db-sig-request@python.org >You can reach the person managing the list at > db-sig-admin@python.org > >(When replying, please edit your Subject line so it is more specific than >"Re: Contents of DB-SIG digest...") > >Today's Topics: > > 1. API Enhancements (M.-A. Lemburg) > 2. Re: oracledb memory leak (Jim Fulton) > 3. Re: API Enhancements (Andy Dustman) > 4. Re: API Enhancements (M.-A. Lemburg) > 5. ODBC VC++ 5 Compilation (Donald A. Daugherty) >Message: 1 >Sender: lemburg@vossnet.de >Message-ID: <36A32169.2ECE2BD@lemburg.com> >Date: Mon, 18 Jan 1999 12:56:25 +0100 >From: "M.-A. Lemburg" >Organization: IKDS >MIME-Version: 1.0 >To: "DB-SIG @ Python.org" >Subject: [DB-SIG] API Enhancements >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >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 > >The old one ist at: > > http://www.python.org/sigs/db-sig/DatabaseAPI.html > >I have some more points that I would like to clarify: > >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. > >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. > >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, >returning a sequence of all known objects of a certain >type in the database, e.g. tables and views, in a predefined >way, e.g. > >db.catalog('tables') > >ODBC has a wide variety of such functions, but they all >return result sets with different schemas. Therefore I'd suggest >having the interface not return a result set, but instead a Python >list using a single format for all types of objects (passing None >for non applicable or unkown entries): > >(qualifier,name,type,owner[,optional additional entries]) > >To find out the column names a function could then use >empty SELECTs and the cursor description attribute, e.g. >c = db.cursor() >c.execute('SELECT * FROM %s WHERE 1=0' % tablename) ># look at c.description > >4. Optional named cursors > >The cursor constructor should be allowed to have an optional >argument for the cursor name. This is useful for UPDATEs. > >Comments ? > >-- >Marc-Andre Lemburg Y2000: 347 days left >--------------------------------------------------------------------- > : Python Pages >>> http://starship.skyport.net/~lemburg/ : > --------------------------------------------------------- > >Message: 2 >Message-ID: <36A37275.375B05C7@digicool.com> >Date: Mon, 18 Jan 1999 12:42:13 -0500 >From: Jim Fulton >Organization: Digital Creations, Inc. >MIME-Version: 1.0 >To: arw@ifu.net >CC: db-sig@python.org >Subject: Re: [DB-SIG] oracledb memory leak >References: <199901162217.RAA01375@python.org> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >arw@ifu.net wrote: >> >> <369ebdf4.919ec6d-@email.sps.mot.com> wrote: >> Original Article: http://www.egroups.com/list/db-sig/?start=596 >> > Hi All, >> > >> > I am using the oracledb extension on HP-UX 10.20 for an intensive and >> > persistent process and am seeing memory leaks that consumes over 100 Mgs >> > >> > before the process finally crashes. Has anyone seen a memory leak >> > problem with the oracledb extension? >> > >> > Does anyone know if there is a Python database extension that is >> > comparable (i.e similar functionallty, API's) to oracledb that will run >> > on HP-UX, AIX and NT 4.0? >> > >> > Thanks for the help, >> > >> > Larry >> >> You didn't specify whether you wanted to stick with Oracle or not. >> If you do, maybe have a look at the odbc or mxodbc modules. > >Oracle's ODBC drivers leak bad. > >Jim > >-- >Jim Fulton mailto:jim@digicool.com >Technical Director (888) 344-4332 Python Powered! >Digital Creations http://www.digicool.com http://www.python.org > >Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email >address may not be added to any commercial mail list with out my >permission. Violation of my privacy with advertising or SPAM will >result in a suit for a MINIMUM of $500 damages/incident, $1500 for >repeats. >Message: 3 >Date: Mon, 18 Jan 1999 12:59:08 -0500 (EST) >From: Andy Dustman >To: "M.-A. Lemburg" >cc: "DB-SIG @ Python.org" >Subject: Re: [DB-SIG] API Enhancements >In-Reply-To: <36A32169.2ECE2BD@lemburg.com> >Message-ID: >Copyright: 1999 by Andy Dustman >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII > >On Mon, 18 Jan 1999, M.-A. Lemburg wrote: > >> 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. > >This, of course, depends on what sort of threading support is built into >the database. Part of the reason this question is being asked is because >of a little e-mail discussion between me and Marc... > >Basically, I have a server app where I have wanted to have a threaded >server using mxODBC, but I could never use it because I always ran into a >memory leak, so I had to switch to a forked model (not a big pain with >SocketServer). However, M.-A. has now found the leak so I can think about >doing this again with mxODBC. > >C extensions in Python are basically thread-safe by default, due to the >global interpreter lock: While the C extension is running, it has the >lock, so no other thread can run. This, by itself, would make a pretty >useless threading implementation, so Guido has some macros in the Python >API to give up and reacquire the lock around sections of code that would >block for arbitrarily long periods of time: Py_BEGIN_ALLOW_THREADS and >Py_END_ALLOW_THREADS. Judicious use of this construct makes a C extension >module what I call thread-friendly. I guess you can manipulate some Python >objects to some extent, but nobody else can be in a position to notice >(like modifying tuples: You can do it, as long as nobody else knows it >exists yet). > >I believe that in practice, if the database's client library is >thread-safe, then the Python interface module for it needs to be >thread-friendly, or else there will be poor performance in threads: Even >if each thread has it's own connection, only one can be using the database >module at any given time, and database accesses will block all threads for >arbitrarily long periods of time. > >Generally I don't think threads should try to share connections mainly >because even if it is thread-safe, it has some very strange implications >for transactions. It may mess up client-server protocols as well. So >sharing cursors becomes a moot point. > >BTW, I have developed a patch against MySQLmodule-1.4 which makes it >thread-friendly; however, I have not been able to test it very well. Any >volunteers. > >> 4. Optional named cursors >> >> The cursor constructor should be allowed to have an optional >> argument for the cursor name. This is useful for UPDATEs. > >This is so easy to implement (at least for ODBC) that there's no good >reason not to do it. Where it doesn't make sense, the API can just ignore >the optional argument. > >-- >Andy Dustman You should always say "spam" and "eggs" >ComStar Communications Corp. instead of "foo" and "bar" >(706) 549-7689 | PGP KeyID=0xC72F3F1D in Python examples. (Mark Lutz) > > >Message: 4 >Sender: lemburg@vossnet.de >Message-ID: <36A38BD2.67E09E67@lemburg.com> >Date: Mon, 18 Jan 1999 20:30:26 +0100 >From: "M.-A. Lemburg" >Organization: IKDS >MIME-Version: 1.0 >To: Andy Dustman >CC: "DB-SIG @ Python.org" >Subject: Re: [DB-SIG] API Enhancements >References: >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Andy Dustman wrote: >> >> On Mon, 18 Jan 1999, M.-A. Lemburg wrote: >> >> > 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. >> >> This, of course, depends on what sort of threading support is built into >> the database. Part of the reason this question is being asked is because >> of a little e-mail discussion between me and Marc... >> >> Basically, I have a server app where I have wanted to have a threaded >> server using mxODBC, but I could never use it because I always ran into a >> memory leak, so I had to switch to a forked model (not a big pain with >> SocketServer). However, M.-A. has now found the leak so I can think about >> doing this again with mxODBC. > >Actually, I found a different leakage than the one announced on >c.l.p. They will both be fixed in the next release which is due later >this week. > >> C extensions in Python are basically thread-safe by default, due to the >> global interpreter lock: While the C extension is running, it has the >> lock, so no other thread can run. This, by itself, would make a pretty >> useless threading implementation, so Guido has some macros in the Python >> API to give up and reacquire the lock around sections of code that would >> block for arbitrarily long periods of time: Py_BEGIN_ALLOW_THREADS and >> Py_END_ALLOW_THREADS. Judicious use of this construct makes a C extension >> module what I call thread-friendly. I guess you can manipulate some Python >> objects to some extent, but nobody else can be in a position to notice >> (like modifying tuples: You can do it, as long as nobody else knows it >> exists yet). >> >> I believe that in practice, if the database's client library is >> thread-safe, then the Python interface module for it needs to be >> thread-friendly, or else there will be poor performance in threads: Even >> if each thread has it's own connection, only one can be using the database >> module at any given time, and database accesses will block all threads for >> arbitrarily long periods of time. >> >> Generally I don't think threads should try to share connections mainly >> because even if it is thread-safe, it has some very strange implications >> for transactions. It may mess up client-server protocols as well. So >> sharing cursors becomes a moot point. > >I've added those thread macros around most long running calls, e.g. >those preparing, executing and fetching data and connects, in mxODBC. >Since I'm not running threaded applications with it, someone else >will have to check whether those macros do no harm to the data integrity >of the various supported databases. > >-- >Marc-Andre Lemburg Y2000: 347 days left >--------------------------------------------------------------------- > : Python Pages >>> http://starship.skyport.net/~lemburg/ : > --------------------------------------------------------- > >Message: 5 >From: "Donald A. Daugherty" >To: >Subject: [DB-SIG] ODBC VC++ 5 Compilation >Date: Tue, 19 Jan 1999 01:09:13 -0800 >Message-ID: <000001be438b$621c75a0$cc36cacc@bigd> >MIME-Version: 1.0 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit >Importance: Normal > >I get numerous errors from wchar.h and then a whole host of other errors >when I try to compile (I downloaded this just today). > >I followed the instructions to the letter (I am only learning VC++ and my >C/C++ experience is limited). Can you shed any light on this? I am >downloading the current M$ universal data access SDK, it was the only thing >I saw when I went looking for the ODBC SDK. It implies that it includes the >ODBC stuff as well. Let me know, I am very interested in getting this >compiled. Thanks! > >Donald A. Daugherty >--------------------Configuration: ODBC - Win32 Debug-------------------- >Compiling... >mxODBC.cpp >G:\DevStudio\VC\INCLUDE\wchar.h(820) : error C2733: second C linkage of >overloaded function 'wmemchr' not allowed >G:\DevStudio\VC\INCLUDE\wchar.h(822) : error C2733: second C linkage of >overloaded function 'wcschr' not allowed >G:\DevStudio\VC\INCLUDE\wchar.h(824) : error C2733: second C linkage of >overloaded function 'wcspbrk' not allowed >G:\DevStudio\VC\INCLUDE\wchar.h(826) : error C2733: second C linkage of >overloaded function 'wcsrchr' not allowed >G:\DevStudio\VC\INCLUDE\wchar.h(828) : error C2733: second C linkage of >overloaded function 'wcsstr' not allowed >G:\Python\Odbc\Windows\mxODBC.cpp(308) : error C2059: syntax error : >'__stdcall' >G:\Python\Odbc\Windows\mxODBC.cpp(2251) : error C2664: >'PyDict_GetItemString' : cannot convert parameter 2 from 'unsigned char >[10]' to 'char *' >G:\Python\Odbc\Windows\mxODBC.cpp(2779) : warning C4273: 'strtod' : >inconsistent dll linkage. dllexport assumed. >G:\Python\Odbc\Windows\mxODBC.cpp(2795) : warning C4018: '==' : >signed/unsigned mismatch >G:\Python\Odbc\Windows\mxODBC.cpp(2851) : warning C4018: '==' : >signed/unsigned mismatch >G:\Python\Odbc\Windows\mxODBC.cpp(3936) : error C2664: 'SQLDescribeCol' : >cannot convert parameter 3 from 'char [20]' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4611) : error C2664: 'SQLTables' : cannot >convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4655) : error C2664: 'SQLTablePrivileges' >: cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4700) : error C2664: 'SQLColumns' : cannot >convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4745) : error C2664: 'SQLColumnPrivileges' >: cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4793) : error C2664: 'SQLForeignKeys' : >cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4837) : error C2664: 'SQLPrimaryKeys' : >cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4881) : error C2664: 'SQLProcedures' : >cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4927) : error C2664: 'SQLProcedureColumns' >: cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(4977) : error C2664: 'SQLSpecialColumns' : >cannot convert parameter 3 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(5024) : error C2664: 'SQLStatistics' : >cannot convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(5162) : error C2086: 'mxODBCursor_Type' : >redefinition >G:\Python\Odbc\Windows\mxODBC.cpp(5265) : error C2664: 'SQLConnect' : cannot >convert parameter 2 from 'char *' to 'unsigned char *' >G:\Python\Odbc\Windows\mxODBC.cpp(5565) : error C2086: 'mxODBC_Type' : >redefinition >G:\Python\Odbc\Windows\mxODBC.cpp(5797) : error C2070: illegal sizeof >operand >Error executing cl.exe. > >ODBC.dll - 22 error(s), 3 warning(s) > > > > From mal@lemburg.com Tue Jan 19 20:35:01 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 19 Jan 1999 21:35:01 +0100 Subject: [DB-SIG] ODBC VC++ 5 Compilation References: <000001be438b$621c75a0$cc36cacc@bigd> Message-ID: <36A4EC75.6E81B596@lemburg.com> [Errors when compiling mxODBC on VC5 using the current MS ODBC SDK] A new version of mxODBC will be out later this week. It fixes a few of those errors. Someone also mentioned these wchar related errors when using VC -- mxODBC doesn't even include wchar.h so I'm not sure where those errors come from. As for some of the others: I'll have a look at them before releasing V1.0.0. -- Marc-Andre Lemburg Y2000: 346 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From tbryan@arlut.utexas.edu Wed Jan 20 00:22:27 1999 From: tbryan@arlut.utexas.edu (Thomas Bryan) Date: Tue, 19 Jan 1999 18:22:27 -0600 (CST) Subject: [DB-SIG] Informix In-Reply-To: <19981218145117.6581.qmail@findmail.com> Message-ID: Does anyone on the list use Informix? I'm working on Solaris and Linux, and I'd like to have a nice Python interface to Informix (SE, OWS, and/or DS). I've had trouble compiling the informixdb module. (Symbol reference errors: "crypt") I'm interested in anyone's experience with informixdb, Kinfxdb, or mxODBC. Thanks. ------------------------------------------- Tom Bryan Applied Research Laboratories University of Texas at Austin From mal@lemburg.com Wed Jan 20 13:15:37 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 20 Jan 1999 14:15:37 +0100 Subject: [DB-SIG] Informix References: Message-ID: <36A5D6F9.1EFA99B5@lemburg.com> Thomas Bryan wrote: > > Does anyone on the list use Informix? I'm working > on Solaris and Linux, and I'd like to have a nice > Python interface to Informix (SE, OWS, and/or DS). > I've had trouble compiling the informixdb module. > (Symbol reference errors: "crypt") You may have to add '-lcrypt' to the Setup line of the module. Some systems have that API in the standard C lib, others don't. > I'm interested in anyone's experience with informixdb, > Kinfxdb, or mxODBC. If you use the ODBC from OpenLink or Intersolv, mxODBC should have no problem connecting to your Informix DB. OpenLink gives away a 2-user/10-connect license version of their driver package for free. With it you can then not only connect to Informix on Unix, but also to just about any database in your network. -- Marc-Andre Lemburg Y2000: 345 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From stephenng@my-dejanews.com Wed Jan 20 14:28:24 1999 From: stephenng@my-dejanews.com (Stephen Ng) Date: Wed, 20 Jan 1999 14:28:24 -0000 Subject: [DB-SIG] ODBC VC++ 5 Compilation Message-ID: I also got the same wchar.h errors. I didn't have time to track down the cause of it though. I "fixed" it by upgrading to the latest Visual C++. Steve -- On Tue, 19 Jan 1999 21:35:01 M.-A. Lemburg wrote: >[Errors when compiling mxODBC on VC5 using the current MS ODBC SDK] > >A new version of mxODBC will be out later this week. It fixes >a few of those errors. Someone also mentioned these wchar related >errors when using VC -- mxODBC doesn't even include wchar.h so >I'm not sure where those errors come from. > >As for some of the others: I'll have a look at them before >releasing V1.0.0. > >-- >Marc-Andre Lemburg Y2000: 346 days left >--------------------------------------------------------------------- > : Python Pages >>> http://starship.skyport.net/~lemburg/ : > --------------------------------------------------------- > > > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://www.python.org/mailman/listinfo/db-sig > > -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums From stephenng@my-dejanews.com Wed Jan 20 14:35:40 1999 From: stephenng@my-dejanews.com (Stephen Ng) Date: Wed, 20 Jan 1999 14:35:40 -0000 Subject: [DB-SIG] fetchone -> dictionary? Message-ID: I'm just getting started with this stuff, so sorry if this is a newbie question/suggestion. Why not have a flavor of fetchone() which returns a dictionary instead a sequence? Then we could write: row = dfetchone() print row['FieldName'] instead of print row[SomeConstantWhichMightChange] Perhaps dfetchall could be implemented as an array of dictionaries? Steve Ng -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums From mal@lemburg.com Wed Jan 20 16:08:41 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 20 Jan 1999 17:08:41 +0100 Subject: [DB-SIG] fetchone -> dictionary? References: Message-ID: <36A5FF89.4B2E9708@lemburg.com> Stephen Ng wrote: > > I'm just getting started with this stuff, so sorry if this is a newbie > question/suggestion. > > Why not have a flavor of fetchone() which returns a dictionary instead a > sequence? Then we could write: > > row = dfetchone() > print row['FieldName'] > > instead of > > print row[SomeConstantWhichMightChange] > > Perhaps dfetchall could be implemented as an array of dictionaries? You can easily achieve this using a Python function (or maybe even a Python class wrapping the DB API cursor interface). The needed position -> name mapping is available through cursor.desription. -- Marc-Andre Lemburg Y2000: 345 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From gstein@lyra.org Thu Jan 21 00:59:57 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 20 Jan 1999 16:59:57 -0800 Subject: [DB-SIG] fetchone -> dictionary? References: Message-ID: <36A67C0D.25E83609@lyra.org> Stephen Ng wrote: > > I'm just getting started with this stuff, so sorry if this is a newbie question/suggestion. > > Why not have a flavor of fetchone() which returns a dictionary instead a sequence? Then we could write: > > row = dfetchone() > print row['FieldName'] > > instead of > > print row[SomeConstantWhichMightChange] > > Perhaps dfetchall could be implemented as an array of dictionaries? Suggestions like these have come up in the past. The reason that a simple tuple is returned is that it is much easier for the module implementor. Rather than requiring all module implementors to deal with more complex data structures, we rely on Python itself to do the work. You can write a simple layer over the cursor object that fills in a dictionary based on the cursor.description results plus the returned tuple. If you check the archives, you'll find a solution that I posted called "dtuple.py" that can wrap a tuple into a lightweight object allowing "row.FieldName" types of access. It may also allow the dict-type access that you describe, but I've forgotton. For example, most implementations of fetchone() access a set of buffers corresponding to the columns that were fetched. The names of those columns, typically, are not readily available at that point in time. Further, the columns might actually represent *functions* or other complex situations. Having to reference those via a string would be *very* difficult. Is it case sensitive? What about spaces? Quoting? etc. Cheers, -g -- Greg Stein, http://www.lyra.org/ From billtut@microsoft.com Thu Jan 21 00:48:52 1999 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 20 Jan 1999 16:48:52 -0800 Subject: [DB-SIG] fetchone -> dictionary? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB90873@RED-MSG-50> From: Greg Stein [mailto:gstein@lyra.org] > > > Suggestions like these have come up in the past. The reason that a > simple tuple is returned is that it is much easier for the module > implementor. Rather than requiring all module implementors to > deal with > more complex data structures, we rely on Python itself to do the work. > You can write a simple layer over the cursor object that fills in a > dictionary based on the cursor.description results plus the returned > tuple. If you check the archives, you'll find a solution that I posted > called "dtuple.py" that can wrap a tuple into a lightweight object > allowing "row.FieldName" types of access. It may also allow the > dict-type access that you describe, but I've forgotton. > dtuple.py indeed does allow a read-only dict-type access to the data. If you can't dig it up in the archives, I know I have a copy here someplace. I think I may have posted a cursor wrapper object that used dtuple as well, but can't recall for sure. Bill From bmueller@fh-harz.de Thu Jan 21 15:50:01 1999 From: bmueller@fh-harz.de (Bernd Müller) Date: Thu, 21 Jan 1999 08:50:01 -0700 Subject: [DB-SIG] problems with informixdb Message-ID: <36A74CA9.C27FD0B6@fh-harz.de> Dear sig-members, i have some problems in using informixdb on linux. Make works fine. But if i do a 'import informixdb' i get a lot of messages like: 'python: can't resolve symbol gl_xxx' I have moved _informixdb.so into /usr/lib! I am using informixdb.ec version 1.11 and informixdb.py version 1.3 Best regards Bernd -- Prof. Dr. Bernd Müller Tel: 03943/659-240 Hochschule Harz e-mail: bmueller@fh-harz.de Friedrichstrasse 57-59 oder: bmueller@acm.org 38855 Wernigerode http://www2.fh-harz.de/~bmueller From tbryan@arlut.utexas.edu Thu Jan 21 14:17:08 1999 From: tbryan@arlut.utexas.edu (Thomas Bryan) Date: Thu, 21 Jan 1999 08:17:08 -0600 (CST) Subject: [DB-SIG] problems with informixdb In-Reply-To: <36A74CA9.C27FD0B6@fh-harz.de> Message-ID: On Thu, 21 Jan 1999, Bernd Müller wrote: > i have some problems in using informixdb on linux. Make works fine. > But if i do a 'import informixdb' i get a lot of messages like: > 'python: can't resolve symbol gl_xxx' > > I have moved _informixdb.so into /usr/lib! > > I am using informixdb.ec version 1.11 and informixdb.py version 1.3 That probably indicates that the correct libraries aren't all linked in. It's probably finding the header files it needs but not linking in a library or two. What does the LIBS line of your Makefile look like? You probably just need to add -lgls and/or -lglx to the LIBS line somewhere. What platform are you on? On my Linux machine, I used this line LIBS=-lasf -lsql -los -lgen -lgls -lglx -lcrypt but on a Sun/Solaris machine LIBS=-lixsql -lixasf -lixgen -lixos -lixgls I don't know that much about the libraries, but those were the ones I used. I just built them yesterday and haven't done extensive testing, but I can "import informixdb" without an error. By the way, is /usr/lib in your PYTHONPATH? You might want to leave _informixdb.so and informixdb.py in the current directory when you first test it. The module should work if the module files are in the directory where you start python. You can worry about moving them to the "right place" when you're sure everything works. Has anyone heard from Bertil Reinhammar recently? I wonder whether he's still maintaining this module. The readme is dated March 1997! ------------------------------------------- Tom Bryan Applied Research Laboratories University of Texas at Austin From tbryan@arlut.utexas.edu Thu Jan 21 14:35:58 1999 From: tbryan@arlut.utexas.edu (Thomas Bryan) Date: Thu, 21 Jan 1999 08:35:58 -0600 (CST) Subject: [DB-SIG] DB-sig meta post Message-ID: Who maintains the DB-Sig web pages under http://www.python.org/sigs/db-sig/? Could we get a link from the main index page to the topic guide? How about an updated list of modules? The lists on http://www.python.org/topics/database/modules.html and http://www.python.org/sigs/db-sig/status.html differ quite a bit. By the way, is Michael McLay still our coordinator? Is it a problem that http://www.python.org/sigs says that DB-Sig expires in Dec 98? Or maybe it means that Michael McLay expires in December 98. ;-) ------------------------------------------- Tom Bryan Applied Research Laboratories University of Texas at Austin From stephenng@my-dejanews.com Thu Jan 21 23:30:09 1999 From: stephenng@my-dejanews.com (Stephen Ng) Date: Thu, 21 Jan 1999 23:30:09 -0000 Subject: [DB-SIG] fetchone -> dictionary? Message-ID: Thanks for the pointers but I haven't been able to locate dtuple.py (I searched the website and newsgroups at http://www.python.org/search/). Can someone point me to it or email it to me? Thanks, Steve -- On Wed, 20 Jan 1999 16:48:52 Bill Tutt wrote: > > >From: Greg Stein [mailto:gstein@lyra.org] >> >> >> Suggestions like these have come up in the past. The reason that a >> simple tuple is returned is that it is much easier for the module >> implementor. Rather than requiring all module implementors to >> deal with >> more complex data structures, we rely on Python itself to do the work. >> You can write a simple layer over the cursor object that fills in a >> dictionary based on the cursor.description results plus the returned >> tuple. If you check the archives, you'll find a solution that I posted >> called "dtuple.py" that can wrap a tuple into a lightweight object >> allowing "row.FieldName" types of access. It may also allow the >> dict-type access that you describe, but I've forgotton. >> > >dtuple.py indeed does allow a read-only dict-type access to the data. >If you can't dig it up in the archives, I know I have a copy here someplace. >I think I may have posted a cursor wrapper object that used dtuple as well, >but can't recall for sure. > >Bill > > -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums From billtut@microsoft.com Fri Jan 22 00:24:40 1999 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 21 Jan 1999 16:24:40 -0800 Subject: [DB-SIG] fetchone -> dictionary? Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB90884@RED-MSG-50> > From: Stephen Ng [mailto:stephenng@my-dejanews.com] > > > Thanks for the pointers but I haven't been able to locate > dtuple.py (I searched the website and newsgroups at > http://www.python.org/search/). > > Can someone point me to it or email it to me? > Attached are dtuple.py and cursor.py Bill begin 600 dtuple.py M(PHC(&1B+G!Y("TM(&=E;F5R:6,@9&%T86)A7!I8V%L;'D@:6YS=&%N8V5S(&]F M($1A=&%B87-E5'5P;&4@;W(@;VYE(&]F(&ET2!T:&4@8V]L=6UN(&YA;65S M+"!F;W)M871S+"!L96YG=&AS+"!A;F0@;W1H97(*2!A('!R;V-E2!T:&4*:6YF;W)M871I;VX@86)O M=70@=&AE(')E;&%T960@9&%T86)A#H@>%LP72P@9&5S8RD*("`@('-E;&8N;F%M M96UA<"`]('L@?0H@("`@9F]R(&D@:6X@2X@02!4=7!L941E2!T:&4*9&5S8W)I M<'1O2!B971W965N(&%T=&5M<'1I;F<@=&\@86-T(&%S M(&$@;&ES=`IO7,G+"`G:71E;7,G M+"`G=F%L=65S)RP@;W(*)VAA6EN9R!T:&4@9&%T82!E;&5M96YT7!E*'-E;&8N M7V1A=&%?*2`]/2!T>7!E*"`H*2`I.@H@("`@("!R971U&5D M("AT=7!L92]L:7-T*2!A;F0@;6%P<&EN9RUS='EL92!A8V-E7!E*&ME>2D@/3T@='EP92@Q*3H*("`@("`@5T*("`@(')E='5R;B!S96QF+E]G971V86QU95\H:V5Y*0H@(`H@ M(&1E9B!?7W-E=&ET96U?7RAS96QF+"!K97DL('9A;'5E*3H*("`@("=3:6UU M;&%T92!I;F1E>&5D("AT=7!L92]L:7-T*2!A;F0@;6%P<&EN9RUS='EL92!A M8V-E7!E*&ME>2D@/3T@='EP92@Q*3H*("`@("`@(R,C M(&YE960@=&\@0H@("`@7-?*'-E;&8I.@H@("`@(E-I;75L871E(&UA<'!I M;F2DZ"B`@("`B4VEM=6QA=&4@ M;6%P<&EN9R=S(&UE=&AO9',B"B`@("!R971U7,G.@H@("`@ M("`@(')E='5R;B!S96QF+E]K97ES7PH@("`@("!I9B!N86UE(#T]("=I=&5M M5\*("`@("`@:68@;F%M92`]/2`G8V]U;G0G.@H@("`@("`@(')E M='5R;B!S96QF+E]C;W5N=%\*("`@("`@:68@;F%M92`]/2`G:6YD97@G.@H@ M("`@("`@(')E='5R;B!S96QF+E]I;F1E>%\*("`@("`@"!I;B!S96QF+E]D97-C7RYN M86UE;6%P+FET96US*"DZ"B`@("`@('9A;'5E6VYA;65=(#T@&-E<'1I;VYS(#T@*&1B:2YN;T5R45R&5C=71E*'-E;&8L('%U97)Y M+"!P87)A;7,]3F]N92DZ"@D):68@<&%R86US/4YO;F4Z"@D)"7!A3H*"0D)2P@<&%R86US*0H)"65X8V5P="!S96QF+F5R7,N M97AC7W9A;'5E+"`B)7-<;D5R&-?=F%L=64L('%U97)Y+"!P87)A;7,I M+"!S>7,N97AC7W1R86-E8F%C:PH)"7-E;&8N7V1E#H@*'-T%LQ.ETL"B`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@('-E;&8N8W5R2AS96QF+&XI.@H)"7)E2AN*0H)"69O Since Bertil Reinhammar is nowhere to be found, I'd like to volunteer to take over as maintainer of the informixdb module. I've made a number of patches to it over the last few months and thought they might be worth sharing with the user group at large, but I'd rather incorporate them into the main distribution than simply post a patch file to the SIG. How, though, does one go about assuming responsibility for someone else's product? If I wanted to make enhancements in future, how (if at all) would that affect the existing copyright? Do you think IV DocEye AB (the current copyright holder) should be contacted about this? And lest I be too presumptuous, are there others who'd like the job? Should we hold elections for the post? :-) Comments, anyone? -- Stephen J. Turner From guido@CNRI.Reston.VA.US Fri Jan 22 19:04:18 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 22 Jan 1999 14:04:18 -0500 Subject: [DB-SIG] Passing the informixdb torch In-Reply-To: Your message of "Fri, 22 Jan 1999 12:38:20 EST." <36A8B78C.C563F666@ix.netcom.com> References: <36A8B78C.C563F666@ix.netcom.com> Message-ID: <199901221904.OAA02692@eric.cnri.reston.va.us> > Since Bertil Reinhammar is nowhere to be found, I'd like to volunteer to > take over as maintainer of the informixdb module. I've made a number of > patches to it over the last few months and thought they might be worth > sharing with the user group at large, but I'd rather incorporate them > into the main distribution than simply post a patch file to the SIG. > > How, though, does one go about assuming responsibility for someone > else's product? If I wanted to make enhancements in future, how (if at > all) would that affect the existing copyright? Do you think IV DocEye > AB (the current copyright holder) should be contacted about this? > > And lest I be too presumptuous, are there others who'd like the job? > Should we hold elections for the post? :-) Good questions. There are some good guidelines in Eric Raymond's "Homesteading the Noosphere" paper. Generally, if the original author doesn't speak up, it's okay to tentatively assume responsibility, and if you do a good job at it, you become the next owner. http://www.tuxedo.org/~esr/writings/homesteading/index.html Regarding the copyright: I haven't seen the informixdb copyright; if it allows you to distribute modified versions, you shouldn't have to get in touch with them. The new copyright will then be jointly owned. --Guido van Rossum (home page: http://www.python.org/~guido/) From tbryan@arlut.utexas.edu Fri Jan 22 19:40:58 1999 From: tbryan@arlut.utexas.edu (Thomas Bryan) Date: Fri, 22 Jan 1999 13:40:58 -0600 (CST) Subject: [DB-SIG] Passing the informixdb torch In-Reply-To: <36A8B78C.C563F666@ix.netcom.com> Message-ID: On Fri, 22 Jan 1999, Stephen J. Turner wrote: > Since Bertil Reinhammar is nowhere to be found, I'd like to volunteer to > take over as maintainer of the informixdb module. Terrific! It would be nice if more of the DB modules had release dates more recent than, say, 1997. > How, though, does one go about assuming responsibility for someone > else's product? Try reading "Homesteading the Noosphere." :-) http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html In section 4, Eric Raymond describes how hackers generally come to take over a project. I suggest at least posting once or twice to comp.lang.python in case Bertil Reinhammar is still involved in Python. > If I wanted to make enhancements in future, how (if at > all) would that affect the existing copyright? Do you think IV DocEye > AB (the current copyright holder) should be contacted about this? Yuck! Copyright issues. Try contacting IV DocEye AB, but the only references I can find on search engines are all in Swedish, which I don't speak. I know someone who does in case you need to know what a particular page says. Just send me a message. Like the README says, anyone can modify and redistribute copies as long as he doesn't charge a fee. (That's a little more restrictive than GPL.) So, you can at least do that under the current copyright. You're just trying to gain the support of the Python and/or DB-SIG community to claim that your modifications are the new "official" version of informixdb. The previous author hasn't done anything with it for over a year. You have my vote. > And lest I be too presumptuous, are there others who'd like the job? ^^^^ Ha! I mean, no. You have my vote unless Bertil Reinhammar suddenly shows up. > Should we hold elections for the post? :-) Elections assume you have competitors, don't they? ;-) ------------------------------------------- Tom Bryan Applied Research Laboratories University of Texas at Austin