From Midha_Sanjeev/ny_technology@explorer.siny.com Thu Apr 1 00:32:12 1999 From: Midha_Sanjeev/ny_technology@explorer.siny.com (Midha_Sanjeev/ny_technology@explorer.siny.com) Date: Wed, 31 Mar 1999 19:32:12 -0500 Subject: [DB-SIG] mxodbc & mxdatetime Message-ID: We downloaded mxdatetime v 1.2.0 and mxodbc v1.01 modules and installed it on win32 machine (NT as well as 98 & 95). I am getting following error while importing MxDateTime module . ===================== Beging Error Stack ========================== Traceback (innermost last): File "", line 1, in ? File "C:\Program Files\Python\DateTime\__init__.py", line 20, in ? from DateTime import * File "C:\Program Files\Python\DateTime\DateTime.py", line 8, in ? from mxDateTime import * File "C:\Program Files\Python\DateTime\mxDateTime\__init__.py", line 7, in ? from mxDateTime import * ImportError: DLL load failed: The specified procedure could not be found. ===================== End Error Stack =========================== Similarly trying import odbc module and getting the following error message ===================== Beging Error Stack ========================== Traceback (innermost last): File "", line 1, in ? ImportError: DLL load failed: The specified module could not be found. ===================== End Error Stack ========================== Similarly trying import ODBC.MySQL module and getting the following error message ===================== Beging Error Stack ========================== Traceback (innermost last): File "", line 1, in ? NameError: Case mismatch for module name ODBC (filename C:\Program Files\Python\win32\odbc.pyd) ===================== End Error Stack ========================== Based on ur instructions, looks like I need to compile the modules using vc++, but I am having difficulty compiling the same. IS THERE ANYWAY I COULD get COMPILED Distribution of the above Appreciate your help... Thanks Sanjeev From gstein@lyra.org Thu Apr 1 01:44:31 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 31 Mar 1999 17:44:31 -0800 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: <37028012.3AB3D8A7@lemburg.com> Message-ID: <3702CF7F.7F407DB7@lyra.org> M.-A. Lemburg wrote: > > Andy Dustman wrote: > > > > eOn Wed, 31 Mar 1999, M.-A. Lemburg wrote: > > > > > To make testing for "multiple result sets supported" possible, > > > I think this API should be an optional method like .rollback: > > > either not be defined (giving an AttributeError) or raise > > > a NotSupportError... which brings us to the next point ;-) > > > > > > · Should we add NotSupportedError as subclass of OperationalError ? Nope. IMO, there are already too many exceptions, and some of them are rather unclear on how they are distinguished from one another. > > > > > > · Is there a strong need for "capability testing" other than using > > > hasattr() ? Nope. > > > > I have no objections to making it an optional method. As for other > > capability testing, I need to think that any program that relies upon some > > capabilty to function is simply going to break (hopefully in an obvious > > way) when it uses a database which doesn't have the capability in > > question. > > Ok. Greg ? I think it should be "optional void behavior, returning None". The lack of a nextset() will probably not utterly break an application like lack of a rollback. The thing here is that a nice behavior exists for nextset when it isn't available: simply return None (which also happens to mean "no more"). The semantics of its presence also match the semantics of its absence. I say leave the bugger in. > > > [...] > > > > This should not actually be part of the specification, but perhaps we need > > a design note, or guidelines for designing applications so that they can > > ported between different databases with a minimum of effort. This makes > > your application more resilient to changes in the DB API as well (though > > it's hardly affecting my application, if at all, and the API shouldn't > > change much more in the future). > > Would make a nice addendum to the spec... or maybe a separate > document. Volunteers ? Andy :-) ? IMO, very few applications need this portability. I'd definitely ask that it be a second document, published in the db-sig area. Review the apps that you have: how many were written to be truly portable? Is your SQL portable? How about those column types? etc. I know mine aren't, so I'm specifically anti-volunteering to do this :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Apr 1 01:47:56 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 31 Mar 1999 17:47:56 -0800 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: Message-ID: <3702D04C.6672E2CE@lyra.org> Andy Dustman wrote: > ... > All of which leads us back to connect(), which we have now established > (yay) is completely database-dependent, so we acknowledge that interface > can't cover everything, which is no real embarassment. This really means > that there should be some design principles involved in writing database > applications. >... > The result of this is, I really only have one module in the system that I > have to modify. If I really wanted to, I could make a new module (or > convert to a package) and subclass only a few methods to make it > compatible with the new database. But then, I shouldn't be depending on > either hasattr() for capability testing; I should RTFM. Some rewriting > when switching databases is going to be inevitable, even if I'm using the > same interface (i.e. mxODBC). Yes! All excellent points, and this is precisely why I view the task of the DBAPI to be "make them similar enough to allow Python programmers to easily jump from one to the next" rather than "all database interaction is truly portable". For the latter, you can't even use SQL despite its "standardization". Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Apr 1 01:52:45 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 31 Mar 1999 17:52:45 -0800 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: Message-ID: <3702D16D.51AF1630@lyra.org> Andy Dustman wrote: >... > Even so, I'm not sure how we would wrap dbm, gdbm, or bsddb to be > compatible with the API, as they have no query language, no (or one) > table, and no columns! Perhaps the wrapper could parse a little SQL, > ignore the specified columns, and just pickle whatever parameters it > finds. It'd be tough, though. I think I'd stick with the shelf > interface... (I actually have a module, SQLDict, that wraps a > dictionary-like interface around a DBI-compatible connection object... > That direction of abstraction is a little easier to do...) "SIG on Tabular Databases in Python This list is intended to work through and resolve issues related to tabular database access from Python. Being somewhat related, this list may also cover persistency issues in Python." If somebody wants to build a little tabular database on top of *dbm, then DBAPI is fine. Note that DBIAPI actually does not require the use of SQL. The execute() method refers to "operation object". db = gjsdbm.connect('myfile') curs = db.cursor() op = gjsdbm.KeyLookup(key='id') count = curs.execute(op, (123,)) print '123:', count count = curs.execute(op, (456,)) print '456:', count This is all quite valid using the DBAPI :-). Cheers, -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Thu Apr 1 02:36:17 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 31 Mar 1999 18:36:17 -0800 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: <36FBA6D4.A6511A1@lemburg.com> <36FE03DA.1646520@lyra.org> <36FE43BB.6A1F45A2@lemburg.com> Message-ID: <3702DBA1.7F4278B7@lyra.org> M.-A. Lemburg wrote: >... > The differentiation between date, time and timestamp is needed > simply because they point to three different informations. A single > date constructor + corresponding type object is not enough for > a module to decide whether to take only the date, the time, or > both parts to format some data to pass to the database. > > Take e.g. a module that uses literal SQL statement formatting > for interfacing. Such a module would not be able to tell > whether to format a date as time only value, timestamp or > date only value. If it were to always pass in timestamp values, > the database would probably raise an error for DATE and TIME > columns. > > So dropping the two constructors renders that kind of interface > useless. Becides, explicitly using the constructors in you > database interface script will surely make them more readable :-) Your constructors aren't sufficient anyhow(!). As I pointed out once before, MySQL has many more varieties than a simple DATE, TIME, and TIMESTAMP. Hell, the TIMESTAMP has about six varieties. However, I do believe that MySQL can always take a fully-qualified date/time and will trim it back as necessary. This implies a single constructor. What is the case for ODBC? Do you actually need to *bind* these differently? (which is the major reason to have these constructors -- input binding!) > As for the type objects: we could group date/time values > collectively under DATETIME. Would that be in your interest ? This would certainly be better. I wouldn't really have a problem if we said that a "column type" of dbmodule.DATETIME existed. There may be many *Python* types which compare equal to that, but those subtypes are at the discretion of the module implementor. I also believe that if a particular database module requires additional granularity for *input* types, then it will have additional constructors beyond the 6-tuple and the ticks. A real problem that we're having here is that we don't have a sufficient review of the extensions that have been made for the different databases. What have module implementors needed to do to get their modules to work? (not just to operate nicer, but to *work*) > > * the 'qmark' paramstyle should not be assumed. All 2.0 DBAPI modules > > must specify the paramstyle attribute (along with apilevel and > > threadsafety). Further, the 'qmark' style is not the best style. Named > > or positional are best, because they allow you to use the same parameter > > multiple times without requiring the user to respecify it over and over. > > For example: "select column_a1, column_b1 from a, b where a.key = :1 and > > b.key = :1". If anything, we should recommend not using the qmark style > > if a module implementor has a choice. > > True. I'll take those comments out. I would like to see a stated preference for 'numeric', 'named', and/or 'pyformat'. They are marginally clearer, and easier to use. > > * a note needs to be added to execute() and executemany() to state that > > parameters should not require any preprocessing before being passed. To > > the client programmer, the interface should appear as if a value is > > going to be "bound" to the input, rather than substituted into the query > > string. > > Not sure, why you want this. The spec already says: > "Parameters may be provided as sequence or > mapping and will be bound to variables in the operation." I see that, but people have still written substitution-based modules rather than binding-based modules. Can we have a footnote on the word bound, that reads: "The term "bound" refers to the process of binding an input value to a database execution buffer. In practical terms, this means that the input value is directly used as a value in the operation. The client should not be required to "escape" the value so that it can be used -- the value should be equal to the actual database value." (edit the text as required and/or others may have suggested edits) > > * I do not understand the difference between OperationalError and > > ProgrammingError. The examples seem to divide the two exceptions > > arbitrarily. What is the "rule" for deciding which is which? > > OperationalErrors are all types of errors that are related > to things that are not necessarily under the control of the > programmer, e.g. lost connections, log full, transaction > could not be performed due to lack of memory or lack of > functionality, etc. > > ProgrammingError refer to things that are under the programmers > control, e.g. he uses a table that does not exist, he specifies > the wrong number of parameters for a statement, uses wrong > SQL syntax, etc. All right. How about this: under "OperationalError" it states "data source name not found". Whose fault is that? The programmer for entering a typo'd DSN, or the administrators for not configuring it? Under ProgrammingError, it states one case is a "table not found." That isn't the programmer's fault cuz somebody deleted the table. Oh, but maybe it is because he misspelled the table name. Oh, and how is the InternalError different than OperationalError? Not my fault the cursor died on me. If I pass an integer that is too large, is that a ProgrammingError or a DataError? The differences here are too fine-grained to be usefully delineated in the specification. We should probably cut the number of exceptions in half. > Hmm, maybe OperationalError wasn't the right choice for > the dynamic .rollback() error after all... > > There is some overlap and in fact some DBs raise ProgrammingErrors > for certain things while others use OperationalError. Maybe we > should make one a subclass of the other... ? I'd say we make two subclasses of Error: InterfaceError, and DatabaseError. > > * I still do not understand the presence of the rowcount attribute. > > *Especially* since the execute() method now says "return value > > undefined." That's bogus. Let's nuke the rowcount attribute and return > > *that* value from execute. No reason to do an execute and then go > > somewhere else for this information. > > The "return value undefined" was done to allow the .execute() > method return the old style return value (which is not easily > implementable for various reasons I already pointed out in > previous mails). The module implementor is free to return > whatever he likes. > > The rowcount definition is somewhat different from the 1.0 > return value spec of .execute(). That's why it's a new attribute. > Again, module implementors could go and simply have .execute() > return whatever the value of .rowcount would be if they like... If we make it undefined, then we are stating that in DBAPI 2.0, it cannot be used (without consulting the db-specific doc). In other words: somebody has to update their client program. If they are going to update their program, then let's make execute() return something rational. > > * for the execute() return value (merged from the rowcount thing), we > > should discriminate between "I know the number and it is X" and "I have > > no idea". The latter should be None. Note that -1 no longer applies > > since the value is only available as part of an execute, rather than a > > random-access. I agree with your earlier comments about needing to > > remove the bit about detecting DML vs DDL vs DQL. I like your current > > text, with the additions of "0 or None for DDL statements" and "None for > > cases where the count cannot be determined". > > The problem with None is that it compares false which would > be ok for DDL (0 or None both are false), but fails to indicate > "don't know" for DQL where 0 could be a possible known row count. If people are looking for None, then they can use "is None" rather than "not". true-ness / false-ness is obviously not the appropriate way to discriminate the values. result = curs.execute(op) if result is None: # database doesn't know how many rows were returned/affected elif result == 0: # no rows returned/affected else: # some positive number of rows were returned/affected For DDL: a database will return 0 or None (whichever is convenient) For DML: a database will return >=0 or None (if it can't determine the number of rows affected... at one time, PostGres couldn't) For DQL: a database will return >=0 or None (if it can't determine the number of rows returned until a fetchXXX() is performed) A footnote with the above three lines would be a handy "implementation hint" for developers. I believe it also fits in with your need to not be required to parse the statement (which I agree is something to avoid!). > As for the random-access vs. return value: some DBs could be > able to calculate the row count only if at least one fetch was > done. So the information might not be available right after the > execute. > > How about defining the return value .execute() as being the > current .rowcount attribute's value as you propose and provide > the .rowcount as additional, possibly optional feature ? Drop rowcount altogether. We don't need multiple ways to access the value. > > * the comment in fetchone() about the underlying cursor should be > > removed. The Python programmer can never access that thing, so the > > comment is irrelevant. The comment about using array fetches and whatnot > > still apply -- in particular, the possible use of the arraysize > > attribute. > > The comment is simply a warning to those who might expect the > fetchone() method to move the cursor by one row. This may be > true for some interfaces (e.g. mxODBC) while being false for others. Understood, but why does the Python programmer care about this? It has no bearing on the interface since they have NO access to that cursor. The fact that it does or does not move forward N rows is moot -- the Python programmer only uses the DBAPI interface which has no "movement" semantics. Could this note be moved under the implementation hints? > > * in all methods that state "an exception is raised..." we should state > > *which* exception. We have a complete set defined at the beginning, so > > this makes sense to do. I would recommend InterfaceError (it is based on > > the interface we provide, rather than the underlying database). Hrm. > > Maybe not. I can see a case where the DB module will simply attempt to > > call the underlying DB function and generate a DB-related exception. > > Thoughts anyone? > > This is hard to do, since the types of errors may very well be > the whole range of possible Python exceptions + the ones defined > in the DB API, e.g. a conversion routine might raise an OverflowError > in case of numeric overflow while raising an InterfaceError in > case a certain internal assertion failed. Good point. I retract my request :-) > > * on nextset(), it might be nice to define a return value that allows > > the user to discriminate these types of results: no more sets (None > > right now); another set with N rows; another set with unknown number of > > rows. The only thing really available for the last one is a negative > > number (e.g. -1), but that seems a bit hokey. Any ideas? > > I've got no experience with multiple result sets, but do that there > was a point to define the return value in the fuzzy way it is > written in the spec. I think it would be useful to have a specified return value, much like we have it for execute(). Strictly speaking, a nextset() is much like execute, but meaning "give me the next part of my operation" ... the client wants to know the results. Can we mark this as an open issue? Maybe somebody will have a good idea. Ooh. I have a proposal: maybe we can have a global named unknownCount. This can be returned by execute() and by nextset(). In both cases, it means "I have no idea". Client programmers should test with an "is" rather than equivalence. Oh, actually, if the underlying type does not specify a cmp() function, then a "==" compares the type name... this an "==" will work for client programmers, too, since the only other return value is a number. (would we still have None as acceptable? ... oh, for nextset(), yes). New comment: should we change the globals to be: apiLevel, threadSafety, and paramStyle? Or maybe underscore-separated? Or leave them? hmm... I think "Python style" says all lower-case for these, mixed signal on the underscore. Thoughts? Cheers, -g -- Greg Stein, http://www.lyra.org/ From adustman@comstar.net Thu Apr 1 05:48:48 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 1 Apr 1999 00:48:48 -0500 (EST) Subject: [DB-SIG] Remaining issues with DB API 2.0 In-Reply-To: <3702DBA1.7F4278B7@lyra.org> Message-ID: On Wed, 31 Mar 1999, Greg Stein wrote: > However, I do believe that MySQL can always take a fully-qualified > date/time and will trim it back as necessary. This implies a single > constructor. Apparently not totally true. M-A and I tested this, and if you pass MySQL a TIMESTAMP with a fractional seconds part, it treats that as an illegal value and sets it to zero. Nuisance. This is true at least with 3.22.19a. I have not tested against 19b. > I would like to see a stated preference for 'numeric', 'named', and/or > 'pyformat'. They are marginally clearer, and easier to use. Are there any databases where the parameter marker is actually an option? I suppose you could use whatever you wanted for MySQL, but it is vastly easier to use 'format' and/or 'pyformat'. > The client should not be required to "escape" the value so that it can > be used -- the value should be equal to the actual database value." I.e., the module should do any escaping, correct? If true, I agree. > I'd say we make two subclasses of Error: InterfaceError, and > DatabaseError. Speaking of which, I can't find a obvious way in the Python API to create an exception with multiple inheritance. Any ideas? > > > * in all methods that state "an exception is raised..." we should state > > > *which* exception. We have a complete set defined at the beginning, so > > > this makes sense to do. I would recommend InterfaceError (it is based on > > > the interface we provide, rather than the underlying database). Hrm. > > > Maybe not. I can see a case where the DB module will simply attempt to > > > call the underlying DB function and generate a DB-related exception. > > > Thoughts anyone? > > > > This is hard to do, since the types of errors may very well be > > the whole range of possible Python exceptions + the ones defined > > in the DB API, e.g. a conversion routine might raise an OverflowError > > in case of numeric overflow while raising an InterfaceError in > > case a certain internal assertion failed. > > Good point. I retract my request :-) This is why I would like to find a way to do multiple inheritance on exceptions in the Python C API... > New comment: should we change the globals to be: apiLevel, threadSafety, > and paramStyle? Or maybe underscore-separated? Or leave them? hmm... I > think "Python style" says all lower-case for these, mixed signal on the > underscore. Thoughts? My reading of the style guide suggests lower-case, no underscores. -- Andy Dustman (ICQ#32922760) 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 Thu Apr 1 08:27:17 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Apr 1999 10:27:17 +0200 Subject: [DB-SIG] mxodbc & mxdatetime References: Message-ID: <37032DE5.59063282@lemburg.com> Midha_Sanjeev/ny_technology@explorer.siny.com wrote: > > We downloaded mxdatetime v 1.2.0 and mxodbc v1.01 modules and > installed it on win32 machine (NT as well as 98 & 95). > > I am getting following error while importing MxDateTime module . > ===================== Beging Error Stack ========================== > Traceback (innermost last): > File "", line 1, in ? > File "C:\Program Files\Python\DateTime\__init__.py", line 20, in ? > from DateTime import * > File "C:\Program Files\Python\DateTime\DateTime.py", line 8, in ? > from mxDateTime import * > File "C:\Program Files\Python\DateTime\mxDateTime\__init__.py", line 7, in ? > from mxDateTime import * > ImportError: DLL load failed: The specified procedure could not be found. > ===================== End Error Stack =========================== This is probably because you are using Python <1.5.2b2. I suggest upgrading to the latest version (in older versions the APIs PyString_InternXXX() were not properly exported in the WinXX DLL). The alternative is recompiling. The mxpyapi.h header file should then apply the following fix automatically: /* These are missing from PC/python_nt.def and thus didn't get included in python1.5.lib on Windows platforms. */ #ifdef MS_WIN32 # define PyString_InternInPlace(x) # define PyString_InternFromString(x) PyString_FromString(x) #endif > Similarly trying import odbc module and getting the following error message > > ===================== Beging Error Stack ========================== > Traceback (innermost last): > File "", line 1, in ? > ImportError: DLL load failed: The specified module could not be found. > ===================== End Error Stack ========================== mxODBC uses mxDateTime, so you get the same error here. > Similarly trying import ODBC.MySQL module and getting the following > error message > > ===================== Beging Error Stack ========================== > Traceback (innermost last): > File "", line 1, in ? > NameError: Case mismatch for module name ODBC > (filename C:\Program Files\Python\win32\odbc.pyd) > ===================== End Error Stack ========================== You have obviously installed the win32all package from Mark Hammond. There are instructions in the docs on what to do about the naming conflict (there is an odbc module in win32all too; it's a different one, though). > Based on ur instructions, looks like I need to compile the modules > using vc++, but I am having difficulty compiling the same. > > IS THERE ANYWAY I COULD get COMPILED Distribution of the above In about a month I expect to be developing on WinXX too, so I'll include my own binaries in the extensions. Right now, I'm relying on others to help me (and thereby helping others ;). -- Marc-Andre Lemburg Y2000: 274 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Thu Apr 1 09:38:13 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Apr 1999 11:38:13 +0200 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: Message-ID: <37033E85.54C713A1@lemburg.com> Andy Dustman wrote: > > > I'd say we make two subclasses of Error: InterfaceError, and > > DatabaseError. > > Speaking of which, I can't find a obvious way in the Python API to create > an exception with multiple inheritance. Any ideas? You mean: how do I create an exception having a predefined base class ? [I don't see a need for multiple inheritance (with more than one base class) in this situation.] Here's an example: /* Create an exception object, insert it into the module dictionary under the given name and return the object pointer; this is NULL in case an error occurred. base can be given to indicate the base object to be used by the exception object. It should be NULL otherwise */ static PyObject *insexc(PyObject *moddict, char *name, PyObject *base) { PyObject *v; char fullname[256]; sprintf(fullname,MXODBC_MODULE".%s",name); v = PyErr_NewException(fullname, base, NULL); if (v == NULL) return NULL; if (PyDict_SetItemString(moddict,name,v)) return NULL; return v; } e.g. if ((mxODBC_Error = insexc(moddict,"Error",PyExc_StandardError)) == NULL) goto onError; if ((mxODBC_InterfaceError = insexc(moddict,"InterfaceError",mxODBC_Error)) == NULL) goto onError; Was that what you meant ? -- Marc-Andre Lemburg Y2000: 274 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Thu Apr 1 09:31:33 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Apr 1999 11:31:33 +0200 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: <37028012.3AB3D8A7@lemburg.com> <3702CF7F.7F407DB7@lyra.org> Message-ID: <37033CF5.44802359@lemburg.com> Greg Stein wrote: > > > > On Wed, 31 Mar 1999, M.-A. Lemburg wrote: > > > > > > > To make testing for "multiple result sets supported" possible, > > > > I think this API should be an optional method like .rollback: > > > > either not be defined (giving an AttributeError) or raise > > > > a NotSupportError... which brings us to the next point ;-) > > > > > > > > · Should we add NotSupportedError as subclass of OperationalError ? > > Nope. IMO, there are already too many exceptions, and some of them are > rather unclear on how they are distinguished from one another. Actually, those exceptions all originated from the odbc module in win32all... weren't you involved in the writing of that module ? You have got a point there about the fuzzyness of the definitions, I won't except the point about them being too many: since they are layered, it is really totally up to the user and the implementor which exceptions to catch or raise and defining exception class is no burdon on programmers (there are simple to use APIs available) even if they choose not to use them. This is the current class layout: StandardError |__Warning |__Error |__InterfaceError |__DataError |__OperationalError |__IntegrityError |__InternalError |__ProgrammingError I would suggest extending the tree to allow Greg's proposed DatabaseError to fit in: StandardError |__Warning |__Error |__InterfaceError |__DatabaseError |__DataError |__OperationalError |__IntegrityError |__InternalError |__ProgrammingError |__NotSupportedError This scheme can be extended by the programmer at will. I'll include cut&paste code in the implementation hints section. > > > > > > > > · Is there a strong need for "capability testing" other than using > > > > hasattr() ? > > Nope. Huh :-) Didn't you bring this up ??! Nevermind, I'm not too keen on having it either, but I do like your clean and simple method using hasattr(). > > > > > > I have no objections to making it an optional method. As for other > > > capability testing, I need to think that any program that relies upon some > > > capabilty to function is simply going to break (hopefully in an obvious > > > way) when it uses a database which doesn't have the capability in > > > question. > > > > Ok. Greg ? > > I think it should be "optional void behavior, returning None". The lack > of a nextset() will probably not utterly break an application like lack > of a rollback. The thing here is that a nice behavior exists for nextset > when it isn't available: simply return None (which also happens to mean > "no more"). The semantics of its presence also match the semantics of > its absence. > > I say leave the bugger in. That makes 2 for "apply the same procedure as for .rollback()" and 1 for "leave it as it is defined now". Any others who would like to jump in ? > > > This should not actually be part of the specification, but perhaps we need > > > a design note, or guidelines for designing applications so that they can > > > ported between different databases with a minimum of effort. This makes > > > your application more resilient to changes in the DB API as well (though > > > it's hardly affecting my application, if at all, and the API shouldn't > > > change much more in the future). > > > > Would make a nice addendum to the spec... or maybe a separate > > document. Volunteers ? Andy :-) ? > > IMO, very few applications need this portability. I'd definitely ask > that it be a second document, published in the db-sig area. > > Review the apps that you have: how many were written to be truly > portable? Is your SQL portable? How about those column types? etc. I > know mine aren't, so I'm specifically anti-volunteering to do this :-) Oh well, on one hand we are constantly arguing in favor of database portability, on the other we simply state "not doable anyways". This doesn't lead anywhere, I'm afraid. The DB API should provide all the means it can to be able to write database portable code. > M.-A. Lemburg wrote: > >... > > The differentiation between date, time and timestamp is needed > > simply because they point to three different informations. A single > > date constructor + corresponding type object is not enough for > > a module to decide whether to take only the date, the time, or > > both parts to format some data to pass to the database. > > > > Take e.g. a module that uses literal SQL statement formatting > > for interfacing. Such a module would not be able to tell > > whether to format a date as time only value, timestamp or > > date only value. If it were to always pass in timestamp values, > > the database would probably raise an error for DATE and TIME > > columns. > > > > So dropping the two constructors renders that kind of interface > > useless. Becides, explicitly using the constructors in you > > database interface script will surely make them more readable :-) > > Your constructors aren't sufficient anyhow(!). Oh, they are w/r to what ANSI-SQL defines. The number types can all be expressed with standard Python numbers, the character types with Python strings and Binary() objects. All that was left were the TIME and TIMESTAMP types. I don't quite understand why you oppose having a bit more variaty in the spec. It can all be coded in Python in a few lines so there's really no big strain on the programmer. > As I pointed out once > before, MySQL has many more varieties than a simple DATE, TIME, and > TIMESTAMP. Hell, the TIMESTAMP has about six varieties. > > However, I do believe that MySQL can always take a fully-qualified > date/time and will trim it back as necessary. This implies a single > constructor. > > What is the case for ODBC? Do you actually need to *bind* these > differently? (which is the major reason to have these constructors -- > input binding!) The main reason is to be ANSI-SQL conform. If the database suppports other types (just have a look at Postgresql), these are bound to be database specific extensions, yet all databases that claim to support ANSI-SQL must provide these few basic types. > > As for the type objects: we could group date/time values > > collectively under DATETIME. Would that be in your interest ? > > This would certainly be better. I wouldn't really have a problem if we > said that a "column type" of dbmodule.DATETIME existed. There may be > many *Python* types which compare equal to that, but those subtypes are > at the discretion of the module implementor. > > I also believe that if a particular database module requires additional > granularity for *input* types, then it will have additional constructors > beyond the 6-tuple and the ticks. Sure, there's nothing to say against that. In fact, database specific extensions should be welcomed. We're only trying to settle on a basic set of features here and the guideline for this should be ANSI-SQL and common experience with existing database APIs, IMO. > A real problem that we're having here is that we don't have a sufficient > review of the extensions that have been made for the different > databases. What have module implementors needed to do to get their > modules to work? (not just to operate nicer, but to *work*) Oh, we have three module implementors on-line ;-) > > > * the 'qmark' paramstyle should not be assumed. All 2.0 DBAPI modules > > > must specify the paramstyle attribute (along with apilevel and > > > threadsafety). Further, the 'qmark' style is not the best style. Named > > > or positional are best, because they allow you to use the same parameter > > > multiple times without requiring the user to respecify it over and over. > > > For example: "select column_a1, column_b1 from a, b where a.key = :1 and > > > b.key = :1". If anything, we should recommend not using the qmark style > > > if a module implementor has a choice. > > > > True. I'll take those comments out. > > I would like to see a stated preference for 'numeric', 'named', and/or > 'pyformat'. They are marginally clearer, and easier to use. Ok. I added a comment as footnote. > > > * a note needs to be added to execute() and executemany() to state that > > > parameters should not require any preprocessing before being passed. To > > > the client programmer, the interface should appear as if a value is > > > going to be "bound" to the input, rather than substituted into the query > > > string. > > > > Not sure, why you want this. The spec already says: > > "Parameters may be provided as sequence or > > mapping and will be bound to variables in the operation." > > I see that, but people have still written substitution-based modules > rather than binding-based modules. Can we have a footnote on the word > bound, that reads: "The term "bound" refers to the process of binding an > input value to a database execution buffer. In practical terms, this > means that the input value is directly used as a value in the operation. > The client should not be required to "escape" the value so that it can > be used -- the value should be equal to the actual database value." Ok. Also added as footnote. > > > * I do not understand the difference between OperationalError and > > > ProgrammingError. The examples seem to divide the two exceptions > > > arbitrarily. What is the "rule" for deciding which is which? > > > > OperationalErrors are all types of errors that are related > > to things that are not necessarily under the control of the > > programmer, e.g. lost connections, log full, transaction > > could not be performed due to lack of memory or lack of > > functionality, etc. > > > > ProgrammingError refer to things that are under the programmers > > control, e.g. he uses a table that does not exist, he specifies > > the wrong number of parameters for a statement, uses wrong > > SQL syntax, etc. > > All right. How about this: under "OperationalError" it states "data > source name not found". Whose fault is that? The programmer for entering > a typo'd DSN, or the administrators for not configuring it? > > Under ProgrammingError, it states one case is a "table not found." That > isn't the programmer's fault cuz somebody deleted the table. Oh, but > maybe it is because he misspelled the table name. > > Oh, and how is the InternalError different than OperationalError? Not my > fault the cursor died on me. > > If I pass an integer that is too large, is that a ProgrammingError or a > DataError? > > The differences here are too fine-grained to be usefully delineated in > the specification. We should probably cut the number of exceptions in > half. No, but we should add another layer for DatabaseErrors as you propose below (see exception layout above). > > Hmm, maybe OperationalError wasn't the right choice for > > the dynamic .rollback() error after all... > > > > There is some overlap and in fact some DBs raise ProgrammingErrors > > for certain things while others use OperationalError. Maybe we > > should make one a subclass of the other... ? > > I'd say we make two subclasses of Error: InterfaceError, and > DatabaseError. See above. > > > * I still do not understand the presence of the rowcount attribute. > > > *Especially* since the execute() method now says "return value > > > undefined." That's bogus. Let's nuke the rowcount attribute and return > > > *that* value from execute. No reason to do an execute and then go > > > somewhere else for this information. > > > > The "return value undefined" was done to allow the .execute() > > method return the old style return value (which is not easily > > implementable for various reasons I already pointed out in > > previous mails). The module implementor is free to return > > whatever he likes. > > > > The rowcount definition is somewhat different from the 1.0 > > return value spec of .execute(). That's why it's a new attribute. > > Again, module implementors could go and simply have .execute() > > return whatever the value of .rowcount would be if they like... > > If we make it undefined, then we are stating that in DBAPI 2.0, it > cannot be used (without consulting the db-specific doc). In other words: > somebody has to update their client program. That depends on the module implementation. I think this part of the spec is much like the connect() part: it is deemed to be database dependent. Note that a return value of "don't know" would have to be possible for .executeXXX() otherwise and this would of course render the return value useless, because if the method can return this value, the database script would still not be able to rely on the return value being meaningful. > If they are going to update their program, then let's make execute() > return something rational. > > > > * for the execute() return value (merged from the rowcount thing), we > > > should discriminate between "I know the number and it is X" and "I have > > > no idea". The latter should be None. Note that -1 no longer applies > > > since the value is only available as part of an execute, rather than a > > > random-access. I agree with your earlier comments about needing to > > > remove the bit about detecting DML vs DDL vs DQL. I like your current > > > text, with the additions of "0 or None for DDL statements" and "None for > > > cases where the count cannot be determined". > > > > The problem with None is that it compares false which would > > be ok for DDL (0 or None both are false), but fails to indicate > > "don't know" for DQL where 0 could be a possible known row count. > > If people are looking for None, then they can use "is None" rather than > "not". > > true-ness / false-ness is obviously not the appropriate way to > discriminate the values. > > result = curs.execute(op) > if result is None: > # database doesn't know how many rows were returned/affected > elif result == 0: > # no rows returned/affected > else: > # some positive number of rows were returned/affected > > For DDL: a database will return 0 or None (whichever is convenient) > For DML: a database will return >=0 or None (if it can't determine the > number of rows affected... at one time, PostGres couldn't) > For DQL: a database will return >=0 or None (if it can't determine the > number of rows returned until a fetchXXX() is performed) > > A footnote with the above three lines would be a handy "implementation > hint" for developers. I believe it also fits in with your need to not be > required to parse the statement (which I agree is something to avoid!). But what use would this definition have: my module could always return None and be in sync with the spec. Still, the return value would have no value for a user of my module. > > As for the random-access vs. return value: some DBs could be > > able to calculate the row count only if at least one fetch was > > done. So the information might not be available right after the > > execute. > > > > How about defining the return value .execute() as being the > > current .rowcount attribute's value as you propose and provide > > the .rowcount as additional, possibly optional feature ? > > Drop rowcount altogether. We don't need multiple ways to access the > value. As I said: it's not just another way to get that information. The rowcount could become available after a .fecthXXX() call, so it's dynamic... hmm, maybe it should be turned into a method. > > > * the comment in fetchone() about the underlying cursor should be > > > removed. The Python programmer can never access that thing, so the > > > comment is irrelevant. The comment about using array fetches and whatnot > > > still apply -- in particular, the possible use of the arraysize > > > attribute. > > > > The comment is simply a warning to those who might expect the > > fetchone() method to move the cursor by one row. This may be > > true for some interfaces (e.g. mxODBC) while being false for others. > > Understood, but why does the Python programmer care about this? It has > no bearing on the interface since they have NO access to that cursor. > The fact that it does or does not move forward N rows is moot -- the > Python programmer only uses the DBAPI interface which has no "movement" > semantics. > > Could this note be moved under the implementation hints? Ok. It's a footnote now. > > > * on nextset(), it might be nice to define a return value that allows > > > the user to discriminate these types of results: no more sets (None > > > right now); another set with N rows; another set with unknown number of > > > rows. The only thing really available for the last one is a negative > > > number (e.g. -1), but that seems a bit hokey. Any ideas? > > > > I've got no experience with multiple result sets, but do that there > > was a point to define the return value in the fuzzy way it is > > written in the spec. > > I think it would be useful to have a specified return value, much like > we have it for execute(). Strictly speaking, a nextset() is much like > execute, but meaning "give me the next part of my operation" ... the > client wants to know the results. > > Can we mark this as an open issue? Maybe somebody will have a good idea. Ok, I'll add it to the open issues section. > Ooh. I have a proposal: maybe we can have a global named unknownCount. > This can be returned by execute() and by nextset(). In both cases, it > means "I have no idea". Client programmers should test with an "is" > rather than equivalence. Oh, actually, if the underlying type does not > specify a cmp() function, then a "==" compares the type name... this an > "==" will work for client programmers, too, since the only other return > value is a number. (would we still have None as acceptable? ... oh, for > nextset(), yes). Ehm,... have you had too much coffee ;-) What's so bad about -1, BTW ? > New comment: should we change the globals to be: apiLevel, threadSafety, > and paramStyle? Or maybe underscore-separated? Or leave them? hmm... I > think "Python style" says all lower-case for these, mixed signal on the > underscore. Thoughts? All the APIs use lower-case and no underscores, so I guess that's not in sync with the rest. [Not that I like this naming scheme, but it's the way it's been in Python for ages.] Uff, made it... ;-) -- Marc-Andre Lemburg Y2000: 274 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Thu Apr 1 10:10:12 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Apr 1999 12:10:12 +0200 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: <37033E85.54C713A1@lemburg.com> Message-ID: <37034604.5EF32376@lemburg.com> I've uploaded a new version of the API (which includes some changes to the exception hierarchy and .nextset()): http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html -- Marc-Andre Lemburg Y2000: 274 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Thu Apr 1 16:57:02 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 1 Apr 1999 11:57:02 -0500 (EST) Subject: [DB-SIG] Remaining issues with DB API 2.0 In-Reply-To: <37033E85.54C713A1@lemburg.com> Message-ID: On Thu, 1 Apr 1999, M.-A. Lemburg wrote: > Andy Dustman wrote: > > > > > I'd say we make two subclasses of Error: InterfaceError, and > > > DatabaseError. > > > > Speaking of which, I can't find a obvious way in the Python API to create > > an exception with multiple inheritance. Any ideas? > > You mean: how do I create an exception having a predefined base class ? > [I don't see a need for multiple inheritance (with more than one > base class) in this situation.] No, I really did mean multple inheritance. I am already using regular single-inheritance (and I DID model off mxODBC :). I may not use multple inheritance for this module, but I will at some point... -- Andy Dustman (ICQ#32922760) 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 Thu Apr 1 21:04:34 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 01 Apr 1999 23:04:34 +0200 Subject: [DB-SIG] Remaining issues with DB API 2.0 References: Message-ID: <3703DF62.546DA54@lemburg.com> Andy Dustman wrote: > > On Thu, 1 Apr 1999, M.-A. Lemburg wrote: > > > Andy Dustman wrote: > > > > > > > I'd say we make two subclasses of Error: InterfaceError, and > > > > DatabaseError. > > > > > > Speaking of which, I can't find a obvious way in the Python API to create > > > an exception with multiple inheritance. Any ideas? > > > > You mean: how do I create an exception having a predefined base class ? > > [I don't see a need for multiple inheritance (with more than one > > base class) in this situation.] > > No, I really did mean multple inheritance. I am already using regular > single-inheritance (and I DID model off mxODBC :). I may not use multple > inheritance for this module, but I will at some point... Ah, ok. I guess you could add a new API to Python/errors.c and send the patch to Guido. There currently is no way to comfortably create exception classes with bases *tuples* (it's easy to add though). Cheers, -- Marc-Andre Lemburg Y2000: 274 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Wed Apr 7 01:01:08 1999 From: adustman@comstar.net (Andy Dustman) Date: Tue, 6 Apr 1999 20:01:08 -0400 (EDT) Subject: [DB-SIG] New MySQL interface now available Message-ID: I am happy to announce that a new Python interface to the MySQL database server has been released. MySQLdb-0.0.0 is an all-new interface, sharing no code with earlier interfaces. The main features are: * conforms to DB-SIG database API version 2.0 (proposed) * thread-safe * thread-friendly (threads will not block each other unneccessarily) * works with latest MySQL 3.22.20a release * Python-esque licensing Since it uses the DB-SIG API, it should be almost completely compatible with MySQLmodule-1.4, aside from the connect() function. On-line documentation is available at: http://starship.python.net/crew/adustman/MySQLdb.html Please send any bug reports or suggestions to:

MySQLdb-0.0.0 - all-new interface to MySQL database server. (06-Apr-99) -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From mal@lemburg.com Wed Apr 7 17:56:23 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 07 Apr 1999 18:56:23 +0200 Subject: [DB-SIG] DB API 2.0 Message-ID: <370B8E37.5C88A557@lemburg.com> Hi everybody, I think the time has come and we can push out the new specification on next Monday. Until then, there's still some cleanup to do like reformatting, spell correction, etc. Does anybody know how to reach Micheal McLay ? The DB sigs pages on www.python.org will need some updates... DB API 1.0: http://starship.skyport.net/~lemburg/DatabaseAPI-1.0.html DB API 2.0: http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html -- Marc-Andre Lemburg Y2000: 268 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Wed Apr 7 21:27:24 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 07 Apr 1999 22:27:24 +0200 Subject: [DB-SIG] Updating the SIG pages Message-ID: <370BBFAC.32658844@lemburg.com> I've just uploaded a cleaned up version of the spec, it's now at 2.0a15. As for the SIG's web-pages: I think there should be a complete rewrite of the SIG's status page. Since Andrew has already done a very fine job with the database topics collection, I think that the status page could be boiled down to a few pointers to his collection and the two API versions. For backward compatibility, we'll need to reference the old API page as DatabaseAPI.html and DatabaseAPI-1.0.html. The new one should be named DatabaseAPI-2.0.html. Future versions can then pick up on this naming scheme. New modules should then probably be published in Andrew's topics guide as sole location. The current setup with some modules on the topics pages, some on the SIG pages and yet some more in the FTP contrib section is not too well suited to make people feel comfortable with the available database connectivity, IMHO. What do you think ? BTW: Even if the SIG is meant for relational databases, wouldn't it be a good idea to open it up for OODBs too ? What about an OODB API (with a DB API compliant adaptor) as new target of discussion ?! -- Marc-Andre Lemburg Y2000: 268 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Wed Apr 7 22:13:31 1999 From: adustman@comstar.net (Andy Dustman) Date: Wed, 7 Apr 1999 17:13:31 -0400 (EDT) Subject: [DB-SIG] Updating the SIG pages In-Reply-To: <370BBFAC.32658844@lemburg.com> Message-ID: On Wed, 7 Apr 1999, M.-A. Lemburg wrote: > BTW: Even if the SIG is meant for relational databases, wouldn't > it be a good idea to open it up for OODBs too ? What about an > OODB API (with a DB API compliant adaptor) as new target of > discussion ?! It sounds like this may be the domain of the DO-SIG (distributed object), which is working on CORBA bindings and such. That doesn't mean we can't butt in, however. :) Does look interesting... -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From akuchlin@cnri.reston.va.us Wed Apr 7 22:32:27 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 7 Apr 1999 17:32:27 -0400 (EDT) Subject: [DB-SIG] Updating the SIG pages In-Reply-To: <370BBFAC.32658844@lemburg.com> References: <370BBFAC.32658844@lemburg.com> Message-ID: <14091.52785.260083.448113@amarok.cnri.reston.va.us> M.-A. Lemburg writes: >As for the SIG's web-pages: I think there should be a complete >rewrite of the SIG's status page. OK; I've radically cut down the status page; the information on it should all be taken into account by the topic guide, anyway. Version 2.0a15 of the spec has been added to the topic guide as well. Comments and further suggestions are welcome. (I still have to add Andy Dustman's new MySQL module, but have a bus to catch at the moment -- do that tomorrow.) Can anyone draw up a list of the major changes between 1.0 and 2.0, and also send an announcement to c.l.py.announce? -- A.M. Kuchling http://starship.python.net/crew/amk/ Alas, despite wing implants, feathers and wax, and carnal associations with swans, we will never grow wings. Alas, any true flight we make will always be externally assisted. Alas, the best we can do is fall and believe ourselves flying. -- Peter Greenaway, _Flying Out of This World_ (1994) From mal@lemburg.com Wed Apr 7 23:58:15 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Apr 1999 00:58:15 +0200 Subject: [DB-SIG] Updating the SIG pages References: <370BBFAC.32658844@lemburg.com> <14091.52785.260083.448113@amarok.cnri.reston.va.us> Message-ID: <370BE307.1CD69255@lemburg.com> Andrew M. Kuchling wrote: > > M.-A. Lemburg writes: > >As for the SIG's web-pages: I think there should be a complete > >rewrite of the SIG's status page. > > OK; I've radically cut down the status page; the information > on it should all be taken into account by the topic guide, anyway. > Version 2.0a15 of the spec has been added to the topic guide as well. > Comments and further suggestions are welcome. (I still have to add > Andy Dustman's new MySQL module, but have a bus to catch at the > moment -- do that tomorrow.) Looks good. Thanks. > Can anyone draw up a list of the major changes between 1.0 and > 2.0, That's one of the things I want to add as additional section before announcing it. > and also send an announcement to c.l.py.announce? I'll do that next Monday... I think we still need a little time to get things just right ;-) -- Marc-Andre Lemburg Y2000: 268 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Thu Apr 8 09:14:23 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Apr 1999 10:14:23 +0200 Subject: [DB-SIG] Updating the SIG pages References: Message-ID: <370C655F.722EFE36@lemburg.com> Andy Dustman wrote: > > On Wed, 7 Apr 1999, M.-A. Lemburg wrote: > > > BTW: Even if the SIG is meant for relational databases, wouldn't > > it be a good idea to open it up for OODBs too ? What about an > > OODB API (with a DB API compliant adaptor) as new target of > > discussion ?! > > It sounds like this may be the domain of the DO-SIG (distributed object), > which is working on CORBA bindings and such. That doesn't mean we can't > butt in, however. :) Does look interesting... Well, I was thinking more in terms of e.g. defining a Python binding for ODMG's OODB model (see http://www.odmg.org). Would be nice to have searchable pickles of Python objects. Unfortunately, they only seem to make the standard documentation available in book form. Since the OQL looks a lot like SQL, maybe even Gadfly could support it... or we could use it's nice parsing features to map OQL onto SQL and then use any of the existing relational DBs as backend. -- Marc-Andre Lemburg Y2000: 267 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Thu Apr 8 09:43:58 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 08 Apr 1999 10:43:58 +0200 Subject: [DB-SIG] Updating the SIG pages References: <370BBFAC.32658844@lemburg.com> <14091.52785.260083.448113@amarok.cnri.reston.va.us> <370BE307.1CD69255@lemburg.com> Message-ID: <370C6C4E.3BB7905E@lemburg.com> M.-A. Lemburg wrote: > > Andrew M. Kuchling wrote: > > > > M.-A. Lemburg writes: > > >As for the SIG's web-pages: I think there should be a complete > > >rewrite of the SIG's status page. > > > > OK; I've radically cut down the status page; the information > > on it should all be taken into account by the topic guide, anyway. > > Version 2.0a15 of the spec has been added to the topic guide as well. > > Comments and further suggestions are welcome. (I still have to add > > Andy Dustman's new MySQL module, but have a bus to catch at the > > moment -- do that tomorrow.) > > Looks good. Thanks. BTW: It would also be nice if there were a link to the original HTML code of the spec, since package writers might want to include it in their documentation (sort of like a "printable version of this page" thing). Ah yes, and we wanted to include the final 2.0 version somewhere in the Python standard docs. Would that be possible ? Even though the standard lib does not include a DB API compatible package, I think it would produce a little more awareness of the specification and Python's database connectivity in general. -- Marc-Andre Lemburg Y2000: 267 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Thu Apr 8 09:48:33 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 8 Apr 1999 04:48:33 -0400 (EDT) Subject: [DB-SIG] Updating the SIG pages In-Reply-To: <370C655F.722EFE36@lemburg.com> Message-ID: On Thu, 8 Apr 1999, M.-A. Lemburg wrote: > Well, I was thinking more in terms of e.g. defining a Python > binding for ODMG's OODB model (see http://www.odmg.org). Would Oh boy, another standards group! I guess http://www.omg.org wasn't enough... (Been researching CORBA stuff all night, argh) -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From akuchlin@cnri.reston.va.us Sun Apr 11 18:22:33 1999 From: akuchlin@cnri.reston.va.us (A.M. Kuchling) Date: Sun, 11 Apr 1999 13:22:33 -0400 Subject: [DB-SIG] Change of DB-SIG ownership Message-ID: <199904111722.NAA01113@207-172-44-186.s186.tnt3.brd.va.dialup.rcn.com> Michael McLay, the current owner of the Database SIG, is very busy with other things these days, and no longer has much time to spend on managing the mailing list and Web page. Therefore, Michael is happy to give up ownership of the SIG, and I'll be taking over the management of the mailing list and DB-SIG Web pages. Thanks to Michael for his efforts in getting this SIG started, and in running it for so long. -- A.M. Kuchling http://starship.python.net/crew/amk/ Time, place, and action may with pains be wrought, / But Genius must be born; and can never be taught. -- John Congreve From mal@lemburg.com Mon Apr 12 10:47:17 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 12 Apr 1999 11:47:17 +0200 Subject: [DB-SIG] About to release DB API 2.0... Message-ID: <3711C125.163C385F@lemburg.com> Hi everybody, DB API 2.0 is ready for take-off. I've done some additional minor editing of the text, spell corrected it and also clarified one tiny issue I found: connection.close() and cursor.close() should cause subsequent actions on the objects to result in an Error exception (or subclass), not just any kind of exception. [Hope this is OK with everybody...:] The final version is available from: http://starship.skyport.net/~lemburg/DatabaseAPI-2.0.html I will post an announcement to the main list and c.l.py.announce later today. Thanks to everybody who contributed to the new version. I think the long discussions were well worthwhile and very helpful. Cheers, -- Marc-Andre Lemburg Y2000: 263 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Wed Apr 14 09:16:51 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Apr 1999 10:16:51 +0200 Subject: [DB-SIG] DB API 2.0... what about NULLs ? Message-ID: <37144EF3.7856CDE6@lemburg.com> I just realized that there is no mention of what to do about SQL NULL values on the Python side of things. Maybe we can sneak that definition into 2.0 before Andrew updates the SIGs web-page... Most interface modules already do the "right thing" w/r to NULL: they simply use None as Python equivalent. This means we could add a sentence: SQL NULL values are represented by the Python None singleton on input and output. and/or add an aliase NULL for None that the module has to define. Any ideas ? -- Marc-Andre Lemburg Y2000: 261 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From davidcuny@yahoo.fr Wed Apr 14 14:42:51 1999 From: davidcuny@yahoo.fr (David Cuny) Date: Wed, 14 Apr 1999 06:42:51 -0700 (PDT) Subject: [DB-SIG] questions... Message-ID: <19990414134251.13038.rocketmail@web703.mail.yahoo.com> Hello, I'd like to realize an Intranet application with a database. My OS is NT, my server is APache and my database is DB2. To use Python through CGI and access data in the database, need I something special? mxODBC??? and ODBC??? I hesitated between python perl and php. Wgat are the advantages to use Python in my case? Thanks answering me. David Cuny _________________________________________________________ ĘTES-VOUS YAHOO!? Votre e-mail @yahoo.fr gratuit sur http://courrier.yahoo.fr From adustman@comstar.net Wed Apr 14 18:24:02 1999 From: adustman@comstar.net (Andy Dustman) Date: Wed, 14 Apr 1999 13:24:02 -0400 (EDT) Subject: [DB-SIG] DB API 2.0... what about NULLs ? In-Reply-To: <37144EF3.7856CDE6@lemburg.com> Message-ID: On Wed, 14 Apr 1999, M.-A. Lemburg wrote: > SQL NULL values are represented by the Python > None singleton on input and output. This is no problem. > and/or add an aliase NULL for None that the module has to define. You know, I might actually do something like this in MySQLdb. On reading from the database, NULLs are returned as Py_None (None). On writing to the databse, a NULL value has to be specified as the token NULL. Part of what I did to pull this off involves defining a string in the _mysql module (the C level), i.e. NULL='NULL'. From an application perspective, however, this None to NULL translation happens transparently (is performed by the Python level); the application reads and writes None to reprsent a NULL value. From an interface perspective, however, I think we should require the above behavior you propose inserting. It is the de facto standard way of doing things, and I think we just overlooked it's abscense, since NULL <--> None is such a natural mapping. NULL should probably not be part of the specification, since if it is, someone will become dependent on it and most interfaces won't have it. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From mal@lemburg.com Wed Apr 14 14:48:49 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Apr 1999 15:48:49 +0200 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: <37144EF3.7856CDE6@lemburg.com> Message-ID: <37149CC1.2DD8C7E3@lemburg.com> M.-A. Lemburg wrote: > > I just realized that there is no mention of what to do about > SQL NULL values on the Python side of things. > > Maybe we can sneak that definition into 2.0 before Andrew updates > the SIGs web-page... > > Most interface modules already do the "right thing" w/r to NULL: > they simply use None as Python equivalent. This means we could add > a sentence: > > SQL NULL values are represented by the Python > None singleton on input and output. > > and/or add an aliase NULL for None that the module has to define. > Here is the text I'd like to add to the Type Objects section: """ NULL SQL NULL values are represented by the Python None singleton on input and output. NULL is an alias for None that the module must define if the database supports NULL values. """ This has the added advantage of being able to check for NULL support via hasattr(), e.g. Gadfly should not define it. If nobody objects, I'll update the spec on starship later today. -- Marc-Andre Lemburg Y2000: 261 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From mal@lemburg.com Wed Apr 14 19:35:14 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Apr 1999 20:35:14 +0200 Subject: [DB-SIG] questions... References: <19990414134251.13038.rocketmail@web703.mail.yahoo.com> Message-ID: <3714DFE2.916F33E@lemburg.com> David Cuny wrote: > > Hello, > > I'd like to realize an Intranet application with a database. My OS is > NT, my server is APache and my database is DB2. > To use Python through CGI and access data in the database, need I > something special? mxODBC??? and ODBC??? Use the win32 odbc module, Sam Rushing's calldll ODBC wrapper or mxODBC. They all have their pros and cons, but I won't comment since I'm biased ;-) > I hesitated between python perl and php. Wgat are the advantages to > use Python in my case? There's a pretty well written language comparison on www.python.org somewhere. I'm doing lot's of CGI stuff: my current project has reached somewhere around 30k lines of Python code... and it's still easy to manage. -- Marc-Andre Lemburg Y2000: 261 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Wed Apr 14 20:06:29 1999 From: adustman@comstar.net (Andy Dustman) Date: Wed, 14 Apr 1999 15:06:29 -0400 (EDT) Subject: [DB-SIG] DB API 2.0... what about NULLs ? In-Reply-To: <37149CC1.2DD8C7E3@lemburg.com> Message-ID: On Wed, 14 Apr 1999, M.-A. Lemburg wrote: > Here is the text I'd like to add to the Type Objects section: > > """ > NULL > SQL NULL values are represented by the Python None singleton > on input and output. NULL is an alias for None that the module must > define if the database supports NULL values. > """ > > This has the added advantage of being able to check for NULL > support via hasattr(), e.g. Gadfly should not define it. > > If nobody objects, I'll update the spec on starship later today. I'll object, for reasons stated earlier: The interface should require None to be the Python equivalent of NULL. Having more that one way to specify NULL values which may or be not be present in a given interface seems to be a good way to create portability problems. This is an even more serious problem than having connect() parameters being interface-dependent (though that one is unavoidable and can be fixed in one place in an application generally). Plus, MySQLdb would run afoul of it, since it defines NULL = 'NULL', but if an application were to see it and make use of it, it would be writing the string literal 'NULL' instead of the token NULL. (Actually, I could be NULL = None in my Python layer, but I really think this is a bad idea.) Drop the "NULL is an alias for None" bit and I'm happy. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From mal@lemburg.com Wed Apr 14 20:22:20 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Apr 1999 21:22:20 +0200 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: Message-ID: <3714EAEC.55C35EE3@lemburg.com> Andy Dustman wrote: > > On Wed, 14 Apr 1999, M.-A. Lemburg wrote: > > > Here is the text I'd like to add to the Type Objects section: > > > > """ > > NULL > > SQL NULL values are represented by the Python None singleton > > on input and output. NULL is an alias for None that the module must > > define if the database supports NULL values. > > """ > > > > This has the added advantage of being able to check for NULL > > support via hasattr(), e.g. Gadfly should not define it. > > > > If nobody objects, I'll update the spec on starship later today. > > I'll object, for reasons stated earlier: The interface should require None > to be the Python equivalent of NULL. Having more that one way to specify > NULL values which may or be not be present in a given interface seems to > be a good way to create portability problems. This is an even more serious > problem than having connect() parameters being interface-dependent (though > that one is unavoidable and can be fixed in one place in an application > generally). Plus, MySQLdb would run afoul of it, since it defines NULL = > 'NULL', but if an application were to see it and make use of it, it would > be writing the string literal 'NULL' instead of the token NULL. (Actually, > I could be NULL = None in my Python layer, but I really think this is a > bad idea.) > > Drop the "NULL is an alias for None" bit and I'm happy. Ok. I'll just add a note then. -- Marc-Andre Lemburg Y2000: 261 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From gstein@lyra.org Wed Apr 14 23:00:37 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 14 Apr 1999 15:00:37 -0700 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: Message-ID: <37151005.6AA6D2FE@lyra.org> Andy Dustman wrote: > > On Wed, 14 Apr 1999, M.-A. Lemburg wrote: > ... > > If nobody objects, I'll update the spec on starship later today. >... > Drop the "NULL is an alias for None" bit and I'm happy. I object, too, for the same reasons stated by Andy. It doesn't really make sense to have an alias for None. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Thu Apr 15 08:05:20 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 15 Apr 1999 09:05:20 +0200 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: <37151005.6AA6D2FE@lyra.org> Message-ID: <37158FB0.1FFC3F82@lemburg.com> Greg Stein wrote: > > Andy Dustman wrote: > > > > On Wed, 14 Apr 1999, M.-A. Lemburg wrote: > > ... > > > If nobody objects, I'll update the spec on starship later today. > >... > > Drop the "NULL is an alias for None" bit and I'm happy. > > I object, too, for the same reasons stated by Andy. It doesn't really > make sense to have an alias for None. The updated version is on my Python Pages. It only contains a mention of using None as NULL. The alias part is gone. BTW, the idea was not to actually use the alias in execute()s, but to be able to test whether the database knows about NULLs. -- Marc-Andre Lemburg Y2000: 260 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From akuchlin@cnri.reston.va.us Thu Apr 15 16:25:00 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Thu, 15 Apr 1999 11:25:00 -0400 (EDT) Subject: [DB-SIG] Three MySQL modules? Message-ID: <199904151525.LAA00843@amarok.cnri.reston.va.us> I haven't yet added Andy Dustman's MySQLdb module to the database topic guide. Can someone clarify the situation with the three MySQL modules? There's James Henstridge's mySQLmodule; the copy on python.org is dated 09-Oct-1997, so it's probably unmaintained. There's Joerg Senekowitsch's MySQLmodule, dated 28-Dec-1998, so it's probably still maintained, and there's Andy Dustman's module, announced earlier this module. Which ones should be listed in the topic guide? I think it's OK to drop the Henstridge one; does the Dustman code supersede the Senekowitsch module? Authors, can you clarify this? -- A.M. Kuchling http://starship.python.net/crew/amk/ But if enough of us dream, if a bare thousand of us dream, we can change the world. We can dream it anew! A world in which no cat suffers from the malice of humans. In which no cats are killed by human caprice. A world that we rule. -- The visionary cat, in SANDMAN #18: "A Dream of a Thousand Cats" From adustman@comstar.net Thu Apr 15 18:19:15 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 15 Apr 1999 13:19:15 -0400 (EDT) Subject: [DB-SIG] DB API 2.0... what about NULLs ? In-Reply-To: <37158FB0.1FFC3F82@lemburg.com> Message-ID: On Thu, 15 Apr 1999, M.-A. Lemburg wrote: > The updated version is on my Python Pages. It only contains a > mention of using None as NULL. The alias part is gone. BTW, > the idea was not to actually use the alias in execute()s, but > to be able to test whether the database knows about NULLs. Oh, well that's another matter. On one hand, the cursor description will tell you what columns are nullable. On the other, this doesn't necessarily tell you if the database allows NULL columns. I see three immediate possibilities: 1) a module attribute nullable which is true if the database supports the concept of a NULL column. 2) Require the interface to translate None into the appropriate false-equivalent data values, i.e. None to '', 0, 0.0, 0L as appropriate, upon writing to the database. No translation would be required on reading. 3) Both of these. Whether or not we should try to slide it into the 2.0 spec is another matter; a little late, perhaps, to be thinking of this, and may fixing something that ain't broke. At least on databases which support NULL columns, the worst that would have to be done is to add nullable = 1. For those not supporting NULL (I suspect virtually all SQL databases support it), it might be difficult to know in advance what the correct data type should be for writing. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From gstein@lyra.org Thu Apr 15 19:56:27 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 15 Apr 1999 11:56:27 -0700 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: Message-ID: <3716365B.3816C39C@lyra.org> Andy Dustman wrote: >... > Whether or not we should try to slide it into the 2.0 spec is another > matter; a little late, perhaps, to be thinking of this, and may fixing > something that ain't broke. At least on databases which support NULL It seems like a non-problem and 2.0 is out the door... Why is this issue a problem? What is going on? At a minimum, 2.0 is done with. Any changes go into the next rev. (IMO, of course :-) -g -- Greg Stein, http://www.lyra.org/ From adustman@comstar.net Thu Apr 15 20:41:25 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 15 Apr 1999 15:41:25 -0400 (EDT) Subject: [DB-SIG] Three MySQL modules? In-Reply-To: <199904151525.LAA00843@amarok.cnri.reston.va.us> Message-ID: On Thu, 15 Apr 1999, Andrew M. Kuchling wrote: > I haven't yet added Andy Dustman's MySQLdb module to the database > topic guide. Can someone clarify the situation with the three MySQL > modules? There's James Henstridge's mySQLmodule; the copy on > python.org is dated 09-Oct-1997, so it's probably unmaintained. > There's Joerg Senekowitsch's MySQLmodule, dated 28-Dec-1998, so it's > probably still maintained, and there's Andy Dustman's module, > announced earlier this module. > > Which ones should be listed in the topic guide? I think it's > OK to drop the Henstridge one; does the Dustman code supersede the > Senekowitsch module? Authors, can you clarify this? I was in contact with Joerg Senekowitsch late last year because of problems I noticed in MySQLmodule-1.4, i.e. no use of Py_BEGIN_ALLOW_THREADS ... Py_END_ALLOW_THREADS. He asked if I wanted to take over maintanence. :) He said he there was going to be a 1.5 version, but I got tired of waiting around for it. Also, the code was real ugly because it was designed to work originally like a perl DBI module (yuck). It also had a Python wrapper, written by James Henstridge. The README in MySQLmodule-1.4 says: MySQLmodule-1.x is based on mySQLmodule-0.1.4 by Copyright (C) 1997 Joseph Skinner Copyright (C) 1997 James Henstridge mySQLmodule-0.1.4 is based on mSQLmodule, which is Portions copyright (C) 1995 Thawte Consulting, cc Portions copyright (C) 1994 Anthony Baxter. See 'Credits' for details. Joerg Senekowitsch (senekow@ibm.net), October 1998 Confused yet? To top it off, the mSQLmodule author (I think it was Baxter) wrote me to thank me for writing a new module and putting a bullet in the old code; he was tired getting questions about it, even though he hadn't maintained it for years. My MySQLdb is only designed to work with MySQL-3.22.19+. I know for a fact that it doesn't presently compile with 3.22.11, because of some new constants which have since been added. I don't expect it to work with 3.21 at all. However, MySQLmodule-1.4 should work with 3.21, so it may yet have some life to it, though use of MySQL-3.21 is discouraged nowadays, I think. Also, MySQLdb is completely new, and shares no code with any earlier interface, and it's 100% free software (others might be as well). OTOH, it's not widely tested yet, but compatible with the 2.0 DB API. They are not 100% compatible, either. If you use MySQLmodule's Mysqldb: >>> import Mysqldb >>> conn = Mysqldb.mysqldb('mysql@localhost root rootpasswd') >>> curs = conn.cursor() >>> curs.execute("insert into user (host, user) values ('%s', '%s')", ... [('localhost', 'linus'), ('somewhere.com.au', 'james')]) Equivalent code for MySQLdb (my module) is: >>> import MySQLdb >>> conn = MySQLdb.connect(user="root", passwd="rootpasswd") >>> curs = conn.cursor() >>> curs.execute("insert into user (host, user) values (%s, %s)", ... [('localhost', 'linus'), ('somewhere.com.au', 'james')]) Note the differences in the query strings. So MySQLdb is definitely not a drop-in replacement, but definitely better for new apps, particularly if threading is desired. So to answer your question, probably both mine and Senekowitsch's ought to be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30 (according to the README). -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From akuchlin@cnri.reston.va.us Thu Apr 15 20:57:52 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Thu, 15 Apr 1999 15:57:52 -0400 (EDT) Subject: [DB-SIG] Three MySQL modules? In-Reply-To: References: <199904151525.LAA00843@amarok.cnri.reston.va.us> Message-ID: <14102.17537.575437.723488@amarok.cnri.reston.va.us> Andy Dustman writes: >So to answer your question, probably both mine and Senekowitsch's ought to >be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30 >(according to the README). Done; I've dropped the Henstridge module completely from the topic guide, though it'll still be available in the contrib directory. -- A.M. Kuchling http://starship.python.net/crew/amk/ I am falling / Like a stone / Being born again / Into the sweet morning fog. -- Kate Bush, "The Morning Fog" From mal@lemburg.com Thu Apr 15 23:40:40 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Apr 1999 00:40:40 +0200 Subject: [DB-SIG] DB API 2.0... what about NULLs ? References: <3716365B.3816C39C@lyra.org> Message-ID: <37166AE8.1FAE25C@lemburg.com> Greg Stein wrote: > > Andy Dustman wrote: > >... > > Whether or not we should try to slide it into the 2.0 spec is another > > matter; a little late, perhaps, to be thinking of this, and may fixing > > something that ain't broke. At least on databases which support NULL > > It seems like a non-problem and 2.0 is out the door... > > Why is this issue a problem? What is going on? > > At a minimum, 2.0 is done with. Any changes go into the next rev. (IMO, > of course :-) Right, we'll keep it in mind for 2.1. I really didn't mean to stir up anything; I was just a little surprised that we forgot the NULLs in all those discussions about .nextset()s and return values ;-) The note I added to the end of the spec merely points out the already used fact that None should be used as NULL on input and output. Nothing more. For now, the main objective is getting some 2.0 compliant modules out there. AFAIK, only Andy's module is 2.0 compliant. I'm working hard on mxODBC... stumbling over all kinds of inconsistencies in the way ODBC is implemented by the various drivers along the way :-/ -- Marc-Andre Lemburg Y2000: 260 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From adustman@comstar.net Fri Apr 16 04:17:52 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 15 Apr 1999 23:17:52 -0400 (EDT) Subject: [DB-SIG] Three MySQL modules? In-Reply-To: <14102.17537.575437.723488@amarok.cnri.reston.va.us> Message-ID: On Thu, 15 Apr 1999, Andrew M. Kuchling wrote: > Andy Dustman writes: > >So to answer your question, probably both mine and Senekowitsch's ought to > >be listed: Mine for MySQL-3.22.19+, and Senekowitsch's for MySQL-3.21.30 > >(according to the README). > > Done; I've dropped the Henstridge module completely from the > topic guide, though it'll still be available in the contrib directory. Another compatibility note: MySQLdb requires Python 1.5.2. Details of why are in the docs on the web page. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From deirdre@deirdre.net Thu Apr 22 03:52:06 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Wed, 21 Apr 1999 22:52:06 -0400 (EDT) Subject: [DB-SIG] Informix on IRIX? Message-ID: I'm using Python on IRIX (among other platforms) and have not been able to successfully make the "Informix" module. I'm going to try Kinfxdb. Has anyone made either of these under IRIX? _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From deirdre@deirdre.net Thu Apr 22 22:52:57 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Thu, 22 Apr 1999 17:52:57 -0400 (EDT) Subject: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: More to the point, I've gotten it to: esql -e kinfxdb.ec /www/informix/bin/esql[351]: /usr/informix/lib/esql/esqlc: not found make: *** [kinfxdb.c] Error 127 ...however, esql isn't a directory! On Wed, 21 Apr 1999, Deirdre Saoirse wrote: > I'm using Python on IRIX (among other platforms) and have not been able to > successfully make the "Informix" module. I'm going to try Kinfxdb. Has > anyone made either of these under IRIX? > > _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net > "At a risk of being called sexist, ageist and French, if you put > multimedia, a leather skirt and lipstick on a grandmother and take her > to a night club, she's still not going to get lucky." -- Jean Louis > Gassee (of Be) on Windows 2000 being "multimedia." > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From johnm@magnet.com Thu Apr 22 23:10:43 1999 From: johnm@magnet.com (John Mitchell) Date: Thu, 22 Apr 1999 18:10:43 -0400 Subject: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Thu, 22 Apr 1999, Deirdre Saoirse wrote: > More to the point, I've gotten it to: > > esql -e kinfxdb.ec > /www/informix/bin/esql[351]: /usr/informix/lib/esql/esqlc: not found > make: *** [kinfxdb.c] Error 127 > > ...however, esql isn't a directory! Try setting your half-dozen-odd environment variables. For example, on my machine: setenv INFORMIXDIR /usr/local/informix/ and I have a "esqlc" in /usr/local/informix/lib/esql/esqlc (which the above is trying to reference), and also /usr/local/informix/demo/esqlc Take a look at /usr/local/informix/installesql. My Informix version is: onstat | head -1 INFORMIX-OnLine Version 7.12.UC1 -- On-Line -- Up 7 days 02:47:27 -- 29520 Kbytes hope this helps. - j From Deirdre Saoirse Thu Apr 22 23:34:12 1999 From: Deirdre Saoirse (Deirdre Saoirse) Date: Thu, 22 Apr 1999 18:34:12 -0400 (EDT) Subject: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Thu, 22 Apr 1999, John Mitchell wrote: > Try setting your half-dozen-odd environment variables. For example, on my > machine: > > setenv INFORMIXDIR /usr/local/informix/ In my case, it's /www/informix (and no, it's not something I can change). However, note that it was looking for /usr/informix.... which doesn't exist! I can't find anywhere where that was set. > and I have a "esqlc" in /usr/local/informix/lib/esql/esqlc (which the > above is trying to reference), and also /usr/local/informix/demo/esqlc > Take a look at /usr/local/informix/installesql. > > My Informix version is: > > onstat | head -1 > > INFORMIX-OnLine Version 7.12.UC1 -- On-Line -- Up 7 days 02:47:27 -- 29520 > Kbytes > > > hope this helps. Not sure what about the last part is relevant.... _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From Deirdre Saoirse Thu Apr 22 23:47:58 1999 From: Deirdre Saoirse (Deirdre Saoirse) Date: Thu, 22 Apr 1999 18:47:58 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: I had the bright-bulb idea of building it as the informix user... > ./bld.sh Platform: IRIX64 Shared lib suffix: Python include dir: /usr/local/include/python1.5 Python config dir: /usr/local/lib/python1.5/config Informix libraries: -lixsql -lixasf -lixgen -lixos -lixgls -lm gcc -c -O -fpic kinfxdb.c -I/usr/local/include/python1.5 -I/usr/local/lib/python1.5/config -I/www/informix/incl/esql "-DPLATFORM=IRIX64" In file included from /usr/local/include/python1.5/Python.h:49, from kinfxdb.ec:7: /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2/include/stdio.h:43: warning: empty declaration as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block: gcc2_compiled. gcc2_compiled.: as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block: __gnu_compiled_c __gnu_compiled_c: as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl initdbi .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl PyDict_SetItemString .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl PyLong_FromLong .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl PyModule_GetDict .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl Py_InitModule4 .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl _iqcftch .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl intofmtasc .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl rjulmdy .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl mktime .text as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl dbiMakeDate .text [snip] as: Error: /kinfxdb.c, line 1: stmt extends past logical end .globl _iqsetconnect .text *** Error code 1 (bu21) > gcc --version 2.7.2.2 Given that the statement on line 1 doesn't...it must be the #include it's barfing at...right? _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From mal@lemburg.com Fri Apr 23 10:35:47 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Apr 1999 11:35:47 +0200 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? References: Message-ID: <37203EF3.4D648781@lemburg.com> Deirdre Saoirse wrote: > > I had the bright-bulb idea of building it as the informix user... > > > ./bld.sh > Platform: IRIX64 > Shared lib suffix: > Python include dir: /usr/local/include/python1.5 > Python config dir: /usr/local/lib/python1.5/config > Informix libraries: -lixsql -lixasf -lixgen -lixos -lixgls -lm > > gcc -c -O -fpic kinfxdb.c -I/usr/local/include/python1.5 > -I/usr/local/lib/python1.5/config -I/www/informix/incl/esql > "-DPLATFORM=IRIX64" > In file included from /usr/local/include/python1.5/Python.h:49, > from kinfxdb.ec:7: > /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2/include/stdio.h:43: > warning: empty declaration > as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block: > gcc2_compiled. > gcc2_compiled.: > as: Warning: /kinfxdb.c, line 1: label should be inside .ent/.end block: > __gnu_compiled_c > __gnu_compiled_c: > as: Error: /kinfxdb.c, line 1: stmt extends past logical end > .globl initdbi .text > [snip] > > as: Error: /kinfxdb.c, line 1: stmt extends past logical end > .globl _iqsetconnect .text > *** Error code 1 (bu21) > > gcc --version > 2.7.2.2 Note that you should normally *never* get error messages from the assembler when compiling a C program. It seems you've got a configuration problem in your compiler setup. I would presume that gcc works best with gas as assembler, yet the dump indicates that it is in fact using some OS supplied assembler. -- Marc-Andre Lemburg Y2000: 252 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From harri.pasanen@trema.com Fri Apr 23 12:59:30 1999 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 23 Apr 1999 13:59:30 +0200 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? References: <37203EF3.4D648781@lemburg.com> Message-ID: <372060A2.54BEC835@trema.com> "M.-A. Lemburg" wrote: > > Note that you should normally *never* get error messages from the > assembler when compiling a C program. It seems you've got a > configuration problem in your compiler setup. I would presume > that gcc works best with gas as assembler, yet the dump indicates > that it is in fact using some OS supplied assembler. > Actually you sometime may get those, as there might be inline assembler code in system headers. For instance, my egcs on Linux refuses to compile files using the default FD_ZERO macro, as FD_ZERO apparently expands to inline assembly code that gcc 2.7.2.3 happily compiles. In these cases my workaround has been to define FD_ZERO myself to pure C code. On other environments than Linux GCC quite often uses system assembler and linker, including system supplied headers and libraries. I don't claim to know what the original posters problem was without seeing the source code. Thank God its Friday, Harri From mal@lemburg.com Fri Apr 23 14:13:06 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Apr 1999 15:13:06 +0200 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? References: <37203EF3.4D648781@lemburg.com> <372060A2.54BEC835@trema.com> Message-ID: <372071E2.5A92CC03@lemburg.com> Harri Pasanen wrote: > > "M.-A. Lemburg" wrote: > > > > Note that you should normally *never* get error messages from the > > assembler when compiling a C program. It seems you've got a > > configuration problem in your compiler setup. I would presume > > that gcc works best with gas as assembler, yet the dump indicates > > that it is in fact using some OS supplied assembler. > > > > Actually you sometime may get those, as there might be inline assembler > code in system headers. For instance, my egcs on Linux refuses to > compile files using the default FD_ZERO macro, as FD_ZERO apparently > expands to inline assembly code that gcc 2.7.2.3 happily compiles. In > these cases my workaround has been to define FD_ZERO myself to pure C > code. Ah, ok, forgot about the inline assembler. I was thinking of assembler code produced by the compiler. Inline assembler can of course cause troubles... > On other environments than Linux GCC quite often uses system assembler > and linker, including system supplied headers and libraries. To the original poster: There is an Informix SDK available for free which includes ODBC drivers. Don't know if they provide IRIX binaries, but that would enable you to connect to Informix using mxODBC. -- Marc-Andre Lemburg Y2000: 252 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From johnm@magnet.com Fri Apr 23 15:38:21 1999 From: johnm@magnet.com (John Mitchell) Date: Fri, 23 Apr 1999 10:38:21 -0400 Subject: [DB-SIG] Re: Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Thu, 22 Apr 1999, Deirdre Saoirse wrote: > I had the bright-bulb idea of building it as the informix user... > > [with gcc, lots of assembler errors appear] On my machine, you cant really use gcc -- SGI's C compiler is pretty good, use that one. If you cant, then as someone said, dork with the configuration. I have two SGIs with 'cc' and 'gcc' on each. Compiling a short program on each of the four variations gives me FOUR different results! Me find big stick now... got a linux box somewhere? :) - j From deirdre@deirdre.net Fri Apr 23 18:49:19 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 13:49:19 -0400 (EDT) Subject: [DB-SIG] Re: Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Fri, 23 Apr 1999, John Mitchell wrote: > I have two SGIs with 'cc' and 'gcc' on each. Compiling a short program on > each of the four variations gives me FOUR different results! Me find big > stick now... Ah. > got a linux box somewhere? :) The problem was that this was going on a production server and I have no choice about that being Linux or SGI. It's SGI. ::sigh:: I don't know much about them (duh!) but it's a "learning experience." _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From deirdre@deirdre.net Fri Apr 23 19:06:54 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 14:06:54 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: <372060A2.54BEC835@trema.com> Message-ID: On Fri, 23 Apr 1999, Harri Pasanen wrote: > I don't claim to know what the original posters problem was without > seeing the source code. It appears, on further investigation, that the gcc was for IRIX 5.3 (if the pathname had anything to do with version) and we're apparently running 6.4: >uname -a IRIX64 coyote 6.4 02121744 IP27 But the source code came right off the python site..it was the informix hooks that started with a k. _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From deirdre@deirdre.net Fri Apr 23 19:19:14 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 14:19:14 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: <372071E2.5A92CC03@lemburg.com> Message-ID: On Fri, 23 Apr 1999, M.-A. Lemburg wrote: > To the original poster: > > There is an Informix SDK available for free which includes > ODBC drivers. Don't know if they provide IRIX binaries, but that > would enable you to connect to Informix using mxODBC. This is a possibility -- thanks for the suggestion. I'll see if we have a support contract with Informix...if so, I'll give them a ring today. I have bigger, hairier problems this morning -- we just launched a web site live that has a new Informix back end...it mails the programmers whenever there's an error and something went wrong with the setup. We were up VERY late last night and I see I have a few thousand more emails this morning. ::sniff:: _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From mal@lemburg.com Fri Apr 23 19:48:20 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Apr 1999 20:48:20 +0200 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? References: Message-ID: <3720C074.2F31470C@lemburg.com> Deirdre Saoirse wrote: > > On Fri, 23 Apr 1999, M.-A. Lemburg wrote: > > > To the original poster: > > > > There is an Informix SDK available for free which includes > > ODBC drivers. Don't know if they provide IRIX binaries, but that > > would enable you to connect to Informix using mxODBC. > > This is a possibility -- thanks for the suggestion. I'll see if we have a > support contract with Informix...if so, I'll give them a ring today. Here is the link to the SDK: http://www.intranet.com > I have bigger, hairier problems this morning -- we just launched a web > site live that has a new Informix back end...it mails the programmers > whenever there's an error and something went wrong with the setup. We were > up VERY late last night and I see I have a few thousand more emails this > morning. ::sniff:: A log file is probably a better idea... but I guess you know by now ;-) Cheers, -- Marc-Andre Lemburg Y2000: 252 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From deirdre@deirdre.net Fri Apr 23 19:51:13 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 14:51:13 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: <3720C074.2F31470C@lemburg.com> Message-ID: On Fri, 23 Apr 1999, M.-A. Lemburg wrote: > > I have bigger, hairier problems this morning -- we just launched a web > > site live that has a new Informix back end...it mails the programmers > > whenever there's an error and something went wrong with the setup. We were > > up VERY late last night and I see I have a few thousand more emails this > > morning. ::sniff:: > > A log file is probably a better idea... but I guess you know by now > ;-) Actually, I'm glad we did it this way. We knew *immediately*. Besides, for those files we write to, we've been getting emails about locking errors.... _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From deirdre@deirdre.net Fri Apr 23 21:31:56 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 16:31:56 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: <372071E2.5A92CC03@lemburg.com> Message-ID: On Fri, 23 Apr 1999, M.-A. Lemburg wrote: > > Actually you sometime may get those, as there might be inline assembler > > code in system headers. For instance, my egcs on Linux refuses to > > compile files using the default FD_ZERO macro, as FD_ZERO apparently > > expands to inline assembly code that gcc 2.7.2.3 happily compiles. In > > these cases my workaround has been to define FD_ZERO myself to pure C > > code. > > Ah, ok, forgot about the inline assembler. I was thinking of > assembler code produced by the compiler. Inline assembler can > of course cause troubles... I switched, per suggestions, from gcc to cc and attempted to recompile. I *know* the fatal error I'm getting now is IRIX related.... ld32: FATAL 12: Expecting n32 objects: /www/informix/lib/esql/libixsql.so is o32. What I don't understand is what it means. As far as all the warnings, I tend to think they're less critical.... _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From johnm@magnet.com Fri Apr 23 21:54:28 1999 From: johnm@magnet.com (John Mitchell) Date: Fri, 23 Apr 1999 16:54:28 -0400 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Fri, 23 Apr 1999, Deirdre Saoirse wrote: > I switched, per suggestions, from gcc to cc and attempted to recompile. > > I *know* the fatal error I'm getting now is IRIX related.... > > ld32: FATAL 12: Expecting n32 objects: /www/informix/lib/esql/libixsql.so > is o32. > > What I don't understand is what it means. argh! Irix switched from "old-style" o32 objects to "new-style" n32, and all your libraries have to match or you're hosed. Since you cant recompile the Informix library above, do a "make clean", then recompile after telling your C compiler to generate "old-style" object files. Hmm. I just found my informix-libary Makefile: LDFLAGS=-shared -all -o32 Try that. Maybe zap the "-shared". If you want, I can post the rest of the makefile for your perusal. - j From deirdre@deirdre.net Fri Apr 23 22:08:01 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 17:08:01 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Fri, 23 Apr 1999, John Mitchell wrote: > argh! Irix switched from "old-style" o32 objects to "new-style" n32, and > all your libraries have to match or you're hosed. Ah! This explains the acronym. :) > Since you cant recompile the Informix library above, do a "make clean", > then recompile after telling your C compiler to generate "old-style" > object files. > > Hmm. I just found my informix-libary Makefile: > > LDFLAGS=-shared -all -o32 > > Try that. Maybe zap the "-shared". If you want, I can post the rest of > the makefile for your perusal. I'd love the makefile...I intend to make the necessary changes to the script after I manage to get it to compile and send them off to the maintainer. :) _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From johnm@magnet.com Fri Apr 23 22:20:05 1999 From: johnm@magnet.com (John Mitchell) Date: Fri, 23 Apr 1999 17:20:05 -0400 Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---792678398-1306080360-924902405=:4212 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Apr 1999, Deirdre Saoirse wrote: > I'd love the makefile...I intend to make the necessary changes to the > script after I manage to get it to compile and send them off to the > maintainer. :) There's nothing magic -- I just took the original Makefile and tweaked a line or three. Enclosed. - j ---792678398-1306080360-924902405=:4212 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=Makefile Iz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KIyBNYWtlZmlsZQ0KIyAkSWQ6IE1ha2VmaWxl LHYgMS40IDE5OTcvMDIvMTkgMTU6MTc6MTYgYmVydGlsIEV4cCBiZXJ0aWwg JCANCiMNCiM9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiMgTWFraW5nIEFuIC5zbyBNb2R1 bGUNCiMgVGhlIHNpbXBsZXN0IHdheSB0byBnZW5lcmF0ZSBhbiBpbmZvcm1p eCBtb2R1bGUgaXMgdG8ganVzdCBydW4gdGhpcw0KIyBNYWtlZmlsZSByaWdo dCBvZiB3aXRoIGVudmlyb25tZW50IHZhcmlhYmxlDQojCUlORk9STUlYRElS DQojIGFuZCBNYWtlZmlsZSB2YXJpYWJsZQ0KIwlQWUlOQ0wNCiMgc2V0IHBy b3Blci4NCiMgSU5GT1JNSVhESVIgaXMgdXN1YWxseSBzZXQgdG8gJy91c3Iv aW5mb3JtaXgnLg0KIyBUaGVuIGNvcHkgdGhlIHJlc3VsdGluZyBpbmZvcm1p eGRiLnNvIHdoZXJldmVyIGFuZCBzZXQgUFlUSE9OUEFUSC4NCiMNCiM9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KIyBOZXZlciBtaW5kIHRoZXNlIHR3bw0KIy1EREFURUZJ WCANCiMgTllJOiAtRERBVEVUSU1FRklYDQojPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiMg Rm9yIFNvbGFyaXMgMi41DQojDQojQ0M9Z2NjICQoREJHRkxHKSAtRFNURVAx IC1ERVhURU5ERURfRVJST1JfSEFORExJTkcNCkNDPWNjICQoREJHRkxHKSAt RFNURVAxIC1ERVhURU5ERURfRVJST1JfSEFORExJTkcgLW8zMlwNCg0KI0lO Rk9STUlYRElSCT0gL3Vzci9sb2NhbC9pbmZvcm1peA0KTEQ9bGQNCkNQPWNw DQojTERGTEFHUz0tRw0KTERGTEFHUz0tc2hhcmVkIC1hbGwgLW8zMg0KREJH RkxHPS1nDQpMRFNVRkY9LnNvDQpMSUJESVJTPSAtTCR7SU5GT1JNSVhESVJ9 L2xpYi9lc3FsIC1MJHtJTkZPUk1JWERJUn0vbGliDQoNCiM9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KIyBGb3IgSFAtVVggMTAuMDENCiMNCiMtIENDPWM4OSAkKERCR0ZM RykgLURTVEVQMSANCiMtIExEPWxkDQojLSBDUD1jcA0KIy0gTERGTEFHUz0t YiAtRQ0KIy0gQ0ZMQUdTPSt6DQojLSBEQkdGTEc9LWcNCiMtIExEU1VGRj0u c2wNCiMtIExJQkRJUlM9IC1MJHtJTkZPUk1JWERJUn0vbGliIC1MJHtJTkZP Uk1JWERJUn0vbGliL2VzcWwNCg0KI1BZSU5DTD0vdXNyL2xvY2FsL2luY2x1 ZGUvcHl0aG9uMS41DQpQWUlOQ0w9L21hZ25ldC91c2Vycy9kYXZlbS9zcmMv UHl0aG9uLTEuNS4xDQoNCiNJTkNMVURFUz0tSSR7SU5GT1JNSVhESVJ9L2lu Y2wvZXNxbCAtSSQoUFlJTkNMKQ0KSU5DTFVERVM9LUkke0lORk9STUlYRElS fS9pbmNsL2VzcWwgLUkkKFBZSU5DTCkgLUkkKFBZSU5DTCkvSW5jbHVkZQ0K TElCUz0tbGFzZiAtbHNxbCAtbG9zIC1sZ2VuDQoNCkZJTEVTRVQgPSBNYWtl ZmlsZSBSRUFETUUgaWZ4ZGJtb2R1bGUuZWMgZGJpLmMgZGJpLmggaW5mb3Jt aXhkYi5weSBcDQoJICBfaW5mb3JtaXhkYi5tYWsgX2luZm9ybWl4ZGIuZGVm DQoNCmFsbDogX2luZm9ybWl4ZGIkKExEU1VGRikNCg0KaWZ4ZGJtb2R1bGUu YzogaWZ4ZGJtb2R1bGUuZWMNCgkkJHtJTkZPUk1JWERJUn0vYmluL2VzcWwg LWUgJDwNCg0KaWZ4ZGJtb2R1bGUubzogaWZ4ZGJtb2R1bGUuYyBkYmkuaA0K CSQoQ0MpICQoQ0ZMQUdTKSAtYyAkPCAkKElOQ0xVREVTKQ0KDQpfaW5mb3Jt aXhkYiQoTERTVUZGKTogaWZ4ZGJtb2R1bGUubyBkYmkubw0KCSQoTEQpICQo TERGTEFHUykgLW8gJEAgJDwgJChMSUJESVJTKSAkKExJQlMpIGRiaS5vICQo TElCUykgJChMSUJTKQ0KCWNobW9kIDc1NSAkQA0KDQpkYmkubzogZGJpLmMg ZGJpLmgNCgkkKENDKSAkKENGTEFHUykgLWMgJDwgJChJTkNMVURFUykNCg0K ZGlzdDoNCgl0YXIgY2YgaW5mb3JtaXhkYi50YXIgJChGSUxFU0VUKQ0KCWd6 aXAgaW5mb3JtaXhkYi50YXINCg0KY2xlYW46DQoJcm0gLXJmICokKExEU1VG RikgKi5vIGlmeGRibW9kdWxlLmMNCg== ---792678398-1306080360-924902405=:4212-- From deirdre@deirdre.net Fri Apr 23 22:37:13 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 17:37:13 -0400 (EDT) Subject: [DB-SIG] Getting warmer! Re: [DB-SIG] Informix on IRIX? In-Reply-To: Message-ID: On Fri, 23 Apr 1999, John Mitchell wrote: Thanks mucho. :) I just looked at your email address. Boy don't I feel like an idiot. :) (working out of the west coast office of the same company....) _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From deirdre@deirdre.net Fri Apr 23 23:19:15 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 23 Apr 1999 18:19:15 -0400 (EDT) Subject: [DB-SIG] Yay and thanks.... In-Reply-To: Message-ID: Well thanks to John's help, I got it to compile. :) Now I just have to test it... :) _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From Deirdre Saoirse Mon Apr 26 00:20:10 1999 From: Deirdre Saoirse (Deirdre Saoirse) Date: Sun, 25 Apr 1999 19:20:10 -0400 (EDT) Subject: [DB-SIG] Next Question (eval version of SOLID) In-Reply-To: Message-ID: Has anyone built SolidPython (or any hooks for SOLID) for the *evaluation* version? I don't really need a heavier weight database for this particular implementation, so this would probably be the best. $ make cc -Wunused -fPIC -g -I/usr/include/python1.5 -I/home/deeny/solidSDK30/Linux_glibc2/include -I. -c soliddb.c -o soliddb.o soliddb.c:33: cli0core.h: No such file or directory soliddb.c:34: cli0ext1.h: No such file or directory make: *** [soliddb.o] Error 1 ...are the errors and indeed these files are not included: $ cd include $ ls cli0cli.h cli0defs.h cli0env.h _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "At a risk of being called sexist, ageist and French, if you put multimedia, a leather skirt and lipstick on a grandmother and take her to a night club, she's still not going to get lucky." -- Jean Louis Gassee (of Be) on Windows 2000 being "multimedia." From adustman@comstar.net Mon Apr 26 02:18:02 1999 From: adustman@comstar.net (Andy Dustman) Date: Sun, 25 Apr 1999 21:18:02 -0400 (EDT) Subject: [DB-SIG] Next Question (eval version of SOLID) In-Reply-To: Message-ID: On Sun, 25 Apr 1999, Deirdre Saoirse wrote: > Has anyone built SolidPython (or any hooks for SOLID) for the *evaluation* > version? I don't really need a heavier weight database for this particular > implementation, so this would probably be the best. SolidPython is horrible. Don't use it. mxODBC works well for Solid. -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From kuppler@vnet.net Mon Apr 26 05:08:31 1999 From: kuppler@vnet.net (kuppler@vnet.net) Date: Mon, 26 Apr 1999 04:08:31 Subject: [DB-SIG] AD:Family Reunion T Shirts & More Message-ID: <199904261153.HAA15541@python.org> Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052, 1-800-810-4330. This list will NOT be sold. All addresses are automatically added to our remove list. Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts, Jackets, Hats, Tote Bags and more! Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to provide you with some great looking T Shirts for your Reunion. Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity (church, school, business etc.) We also can provide you with quality embroidery. We are a family owned company with over 15 years of experience. All work is done at this location. No middle man. Our prices are great! Click reply to email us or call 1-800-810-4330 for more info Bill Kuppler Graphics From deirdre@deirdre.net Fri Apr 30 21:08:12 1999 From: deirdre@deirdre.net (Deirdre Saoirse) Date: Fri, 30 Apr 1999 16:08:12 -0400 (EDT) Subject: [DB-SIG] Informixdb hooks: questions again In-Reply-To: Message-ID: OK, now that I think we have everything set up...theres NO docs.. What do I pass in the informixdb.informixdb statement? Would it be the same order as in Javascript? ('INFORMIX', hostname, username, password, database)? _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "Solving today's problems tomorrow, with yesterday's technology." From johnm@magnet.com Fri Apr 30 22:04:30 1999 From: johnm@magnet.com (John Mitchell) Date: Fri, 30 Apr 1999 17:04:30 -0400 Subject: [DB-SIG] Re: Informixdb hooks: questions again In-Reply-To: Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---792678398-313455780-925506270=:4212 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 30 Apr 1999, Deirdre Saoirse wrote: > OK, now that I think we have everything set up...theres NO docs.. docs? you mean, besides the code? :) > What do I pass in the informixdb.informixdb statement? Would it be the > same order as in Javascript? ('INFORMIX', hostname, username, password, > database)? Check out enclosed file, which I use as the lowest-level Python object. Following this paragraph is the next higher stuff, which deals with stage-vs-live setup issues. SQL reminds me of "Worse is Better" by Richard Gabriel at http://www.jwz.org/worse-is-better.html - j # to test db connection: # # python -c 'import ad_db ; db=ad_db.open() ; # db.execute('select * from sponsor_slot') ; print db.fetchall() # # $Id: ad_db.py,v 1.2 1998/09/15 15:20:06 johnm Exp $ import mysite # plays with sys.path import sys import informixdb, os debug = 0 _informix_vars = [ # host-specific parameters: # (['maroon','lingua'], None, ( "adserver@ifmx_maroon", "dbuser", 'dbpass')), (['maroon','lingua'], 'INFORMIXDIR', '/www/informix'), (['maroon','lingua'], 'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'), (['maroon','lingua'], 'INFORMIXSERVER', 'ifmx_maroon'), # shared-mem (['peach'], None, ( "ads@ifmx_peach_shm", "dbuserdb", 'dbpass')), (['peach'], 'INFORMIXDIR', '/www/informix'), (['peach'], 'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'), (['peach'], 'INFORMIXSERVER', 'ifmx_peach_shm'), # shared-mem # (['peach'], 'INFORMIXSERVER', 'ifmx_peach'),# normal (['violet'], None, ( "ads@ifmx_violet", "dbuserdb", 'dbpass')), (['violet'], 'INFORMIXDIR', '/www/informix'), (['violet'], 'INFORMIXSQLHOSTS', '/www/informix/etc/sqlhosts.ifmx'), (['violet'], 'INFORMIXSERVER', 'ifmx_violet'), # shared-mem # (['violet'], 'INFORMIXSERVER', 'ifmx_violet'),# normal # generic defaults (must be last): # (None, None, ( "ads@ifmx_dingdong", "magdev", 'dbpass')), (None, 'INFORMIXSERVER', 'ifmx_tsunami'), (None, 'INFORMIXDIR', '/usr/local/informix'), (None, 'INFORMIXSQLHOSTS', '/usr/local/informix/etc/sqlhosts.ifmx'), (None, 'INFORMIXTERM', 'terminfo'), ] global _informix_login # XX ugh! _informix_login = None # X: global '_informix_login' modified # def setup(myHostname): # set any missing Informix environment variables. # Ack! # env = os.environ global _informix_login _informix_login = None for hostlist, k,v in _informix_vars: if not hostlist or myHostname in hostlist: # set login information # if not k: if not _informix_login: _informix_login = v continue # set environment info # (allow shell's environment to override us): # if not env.has_key(k): if debug: sys.stderr.write("set: %s\t%s\n" % (k,v)) env[k] = v else: if debug: sys.stderr.write("env: %s\t%s\n" % (k,v)) # X: global '_informix_login' used # def open(hostname=None): if not hostname: import socket hostname = socket.gethostname() setup(hostname) # XX: sigh db = None if _informix_login: db = apply(informixdb.informixdb, _informix_login) else: raise KeyError, "%s: host not recognized" % hostname return db def test(hostname=None): db = open(hostname) db.execute('select * from dummy') # XX assumes this table exists! print db.fetchall() if __name__=="__main__": print test() ---792678398-313455780-925506270=:4212 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="informixdb.py" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: informixdb.py Content-Disposition: attachment; filename="informixdb.py" IyAkSWQ6IGluZm9ybWl4ZGIucHksdiAxLjEuMS4xIDE5OTgvMDgvMzEgMjE6 MzY6MTkgbWF5byBFeHAgJA0KIyBpbmZvcm1peGRiLnB5DQojDQojIFRoaXMg aXMgYSB0cml2aWFsIHB5dGhvbiB3cmFwcGVyIGFyb3VuZCB0aGUgQyBjb3Jl IF9pbmZvcm1peGRiLnNvDQojDQojIEFjY29yZGluZyB0byB0aGUgREJBUEkg c3BlYywgYSBjb25uZWN0aW9uIG9iamVjdCBpcyBleHBlY3RlZCB0byBzdXBw bHkNCiMgdGhlIHNhbWUgc2V0IG9mIGZ1bmN0aW9ucyBhcyBkbyBhIGN1cnNv ciBvYmplY3QuIFRoaXMgaXMgZml4ZWQgaGVyZSBieQ0KIyBhbiBpbXBsaWNp dCBjdXJzb3IuDQojDQojIE5ZRCA9IE5vdCBZZXQgRGVmaW5lZCBieSBEQkFQ SQ0KIyBOWUkgPSBOb3QgWWV0IEltcGxlbWVudGVkDQojDQp0cnk6DQogICAg aW1wb3J0IF9pbmZvcm1peGRiDQpleGNlcHQgSW1wb3J0RXJyb3IsIG1zZzoN CiAgICByYWlzZSBJbXBvcnRFcnJvciwgKCJDYW5ub3QgbG9hZCBDIGNvcmUg bW9kdWxlIGZvciAiDQoJCQkiaW5mb3JtaXggZGIgaW50ZXJmYWNlOlxuXHQl cyIgJSBtc2cpDQoNCg0KY2xhc3MgaW5mb3JtaXhkYjoNCiAgICBkZWYgX19p bml0X18oc2VsZiwgbG9nb24sIHVzZXIsIHBhc3N3b3JkKToNCglzZWxmLmNv bm4gPSBfaW5mb3JtaXhkYi5pbmZvcm1peGRiKGxvZ29uLCB1c2VyLCBwYXNz d29yZCkNCglzZWxmLl9jdXJzb3IgPSBzZWxmLmNvbm4uY3Vyc29yKCkNCglz ZWxmLl9sYXN0X3NxbCA9IE5vbmUNCg0KICAgIGRlZiBfX2dldGF0dHJfXyhz ZWxmLCBhdHRyKToNCglpZiBhdHRyID09ICdkZXNjcmlwdGlvbic6DQoJICAg IHJldHVybiBzZWxmLl9jdXJzb3IuZGVzY3JpcHRpb24NCgllbGlmIGF0dHIg PT0gJ2FycmF5c2l6ZSc6DQoJICAgIHJldHVybiBzZWxmLl9jdXJzb3IuYXJy YXlzaXplDQoJZWxpZiBhdHRyID09ICdlcnJvcic6DQoJICAgIHJldHVybiBf aW5mb3JtaXhkYi5lcnJvcg0KCWVsaWYgYXR0ciA9PSAnc3FsJzoNCgkgICAg cmV0dXJuIHNlbGYuX2xhc3Rfc3FsDQoJZWxzZToNCgkgICAgcmFpc2UgQXR0 cmlidXRlRXJyb3IsIGF0dHINCg0KICAgIGRlZiBpc1ZhbGlkKHNlbGYpOg0K CXNlbGYuZXhlY3V0ZSgnc2VsZWN0IGNvdW50KCopIGZyb20gc3lzdGFibGVz JykNCglzZWxmLmZldGNoYWxsKCkNCglyZXR1cm4gMQ0KDQogICAgZGVmIGNv bW1pdChzZWxmKToNCglzZWxmLmNvbm4uY29tbWl0KCkNCg0KICAgIGRlZiBy b2xsYmFjayhzZWxmKToNCglzZWxmLmNvbm4ucm9sbGJhY2soKQ0KDQogICAg ZGVmIGN1cnNvcihzZWxmKToNCglyZXR1cm4gc2VsZi5jb25uLmN1cnNvcigp DQoNCiAgICBkZWYgY2FsbHByb2Moc2VsZiwgcGFyYW1zID0gTm9uZSk6DQoJ cGFzcyAjIE5ZRA0KDQogICAgZGVmIGV4ZWN1dGUoc2VsZiwgKmFyZ3MpOg0K CXNlbGYuX2xhc3Rfc3FsID0gYXJncw0KCWFwcGx5KHNlbGYuX2N1cnNvci5l eGVjdXRlLCBhcmdzKQ0KDQogICAgZGVmIGZldGNob25lKHNlbGYpOg0KCXJl dHVybiBzZWxmLl9jdXJzb3IuZmV0Y2hvbmUoKQ0KDQogICAgZGVmIGZldGNo bWFueShzZWxmLCBzaXplID0gTm9uZSk6DQoJcmV0dXJuIHNlbGYuX2N1cnNv ci5mZXRjaG1hbnkoc2l6ZSkNCg0KICAgIGRlZiBmZXRjaGFsbChzZWxmKToN CglyZXR1cm4gc2VsZi5fY3Vyc29yLmZldGNoYWxsKCkNCg0KICAgIGRlZiBj bG9zZShzZWxmKToNCglzZWxmLl9jdXJzb3IuY2xvc2UoKQ0KCXNlbGYuY29u bi5jbG9zZSgpDQoJc2VsZi5fY3Vyc29yID0gTm9uZQ0KCXNlbGYuY29ubiA9 IE5vbmUNCg0KICAgIGRlZiBzZXRpbnB1dHNpemVzKHNlbGYsIHNpemVzKToN CglwYXNzICMgTllEDQoNCiAgICBkZWYgc2V0b3V0cHV0c2l6ZXMoc2VsZiwg c2l6ZXMsIGNvbCA9IE5vbmUpOg0KCXBhc3MgIyBOWUQNCg0KICAgIGRlZiB1 bmxvYWQoc2VsZiwgZmlsZSwgc3FsLCBzZXBlcmF0b3I9Tm9uZSk6DQogICAg ICAgIGltcG9ydCBzdHJpbmcNCiAgICAgICAgDQogICAgICAgIGJhdGNoc2l6 ZQk9IDIwDQogICAgICAgIHNlcGVyYXRvcgk9IHNlcGVyYXRvciBvciAnfCcN CiAgICAgICAgb3V0cHV0CQk9IG9wZW4oZmlsZSwgJ3cnKQ0KDQogICAgICAg IGMJCT0gc2VsZi5jdXJzb3IoKQ0KICAgICAgICBjLmV4ZWN1dGUoc3FsKQ0K ICAgICAgICB3aGlsZSAxOg0KICAgICAgICAgICAgYmF0Y2hkYXRhCT0gYy5m ZXRjaG1hbnkoYmF0Y2gpDQogICAgICAgICAgICBpZiBub3QgYmF0Y2hkYXRh Og0KICAgICAgICAgICAgICAgIGJyZWFrDQogICAgICAgICAgICBmb3Igcm93 IGluIGJhdGNoZGF0YToNCiAgICAgICAgICAgICAgICBvdXRwdXQud3JpdGUo IHN0cmluZy5qb2luKHJvdywgc2VwZXJhdG9yKSApDQogICAgICAgICAgICAg ICAgb3V0cHV0LndyaXRlKCAnXG4nICkNCiAgICAgICAgb3V0cHV0LmNsb3Nl KCkNCiAgICAgICAgYy5jbG9zZSgpDQogICAgICAgIA0K ---792678398-313455780-925506270=:4212--