From jekabs.andrusaitis@tietoenator.com Tue Oct 1 09:45:59 2002 From: jekabs.andrusaitis@tietoenator.com (Jekabs Andrushaitis) Date: Tue, 1 Oct 2002 10:45:59 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033406964.1338.130.camel@momo> Message-ID: <001f01c26926$f7d65dd0$262a949f@konts.lv> I am using psycopg module to access PostgreSQL in Python. It is fast, is DBAPI-2.0 compliant, I have never encountered any bugs or glitches. I am using it for couple intranet sites in my company, and it has never failed me. The environment it works in is Apache, mod_python, Python, psycopg and PostgreSQL for completely dynamic sites with about 10000 requests served daily. I am not saying that it is best, however my advice is not to use Python module supplied with PostgreSQL sources... Jekabs Andrushaitis Senior system analyst TietoEnator Financial Solutions 41 Lacplesa Str. Riga, LV-1011, Latvia Tel: +371 7286660 Fax: +371 7243000 E-mail: jekabs.andrusaitis@tietoenator.com > -----Original Message----- > From: db-sig-admin@python.org > [mailto:db-sig-admin@python.org]On Behalf > Of Federico Di Gregorio > Sent: pirmdiena, 2002. gada 30. septembr=CF 19:29 > To: Python DB-SIG Mailing List > Subject: Re: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL > > > Il lun, 2002-09-30 alle 19:11, Marcelo Pereira ha scritto: > > Hi there (again), > > > > I have download these Python interfaces to PostgreSQL and I > haven't find > > any documentation (just some examples, basic and advanced, but just > > examples). > > > > Which is the better one?? (I know this is a question like: > "PostgreSQL or > > MySQL", "RedHat or Slackware", "Vi or Emacs", ..., or > another religious > > question...) I just want to know which is more efficient. > > i can't say "this one is better" but i can say that psycopg is very > solid and almost bug-free. it is also quite fast (it was designed for > speed) but i never tried a benchmark, mainly because i think > benchmarks > should be done on real-world cases. note that i am its main author, > maybe you want to wait for others' module authors to speak on > this list > before going for it.. :) > > > Which module do you use? I would be happy if I had a > reference manual > > (from any one: Popy, Psycopg, PyPgSQL or PyGreSQL). > > they all implement the dbapi-2.0 to some extent, so you should be fine > by just reading the PEP. psycopg has a lot of example code in > doc/examples/ and support some nice dbapi-2.0 extensions like > connection > pooling, user-defined typecasters (to conver postgres data ti python > objects), etc. > > hope this helps, > federico > > -- > Federico Di Gregorio > Debian GNU/Linux Developer & Italian Press Contact > fog@debian.org > INIT.D Developer > fog@initd.org > God is real. Unless declared integer. -- Anonymous FORTRAN > programmer > From magnus@thinkware.se Tue Oct 1 11:21:19 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 12:21:19 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <001f01c26926$f7d65dd0$262a949f@konts.lv> References: <1033406964.1338.130.camel@momo> Message-ID: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> At 10:45 2002-10-01 +0200, Jekabs Andrushaitis wrote: >I am not saying that [psycopg] is best, however my advice is >not to use Python module supplied with PostgreSQL sources... Why not? In general I don't mind diversity, but I four drivers for the same database seems a bit redundant. Any chance that some of these will merge? After all, largely due to open source, we are going towards more and more of a component architecture in our software solutions, and we use different libraries and frameworks for different parts of the system. A library or framework that is built in python and use PostgreSQL might use any of these four drivers. Thus, if we pick several of these components, that do different things, we might end up with several different and possibly conflicting database drivers for communication between Python and PostgreSQL. I haven't been bitten by this yet, but it seems a bit confusing to me... Also, I imagine that the remaining of these drivers could become even better if all the development, testing and documentation attention was focused on that. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From hazmat@objectrealms.net Tue Oct 1 13:28:54 2002 From: hazmat@objectrealms.net (hazmat) Date: Tue, 1 Oct 2002 05:28:54 -0700 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> References: <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> Message-ID: <200210010528.54909.hazmat@objectrealms.net> On Tuesday 01 October 2002 03:21 am, Magnus Lycka wrote: > At 10:45 2002-10-01 +0200, Jekabs Andrushaitis wrote: > >I am not saying that [psycopg] is best, however my advice is > >not to use Python module supplied with PostgreSQL sources... > > Why not? > > > In general I don't mind diversity, but I four > drivers for the same database seems a bit redundant. imho, i would only use pyscopg or pypgsql. of the four they are under the most active development. basically my deciding factor is whether i want to use libpq (pgsql c client lib) or python db-api or if i want to use zope, if db-api i generally would recommend pyscopg as it implements db-api compliance at the c level over libpq. pypgsql is a c extension binding over libpq, with db-api interface written in python. if zope, i would use psycopg as it has extensive testing in that area, and converts to mxDateTimes to ZopeTimes. imho, the two bindings serve different audiences. > Any chance that some of these will merge? not likely. > After all, largely due to open source, we are > going towards more and more of a component > architecture in our software solutions, and we > use different libraries and frameworks for different > parts of the system. A library or framework that > is built in python and use PostgreSQL might use > any of these four drivers. not really, the limitations/bugs of some of the drivers will become apparent quickly. > Thus, if we pick several of these components, that > do different things, we might end up with several > different and possibly conflicting database drivers > for communication between Python and PostgreSQL. I > haven't been bitten by this yet, but it seems a > bit confusing to me... ideally their would be a driver framework with plugins, and we'd only have to worry about the portability of our sql. as it is, most people implement their own abstraction layer, as it does not seem apparent to me, that the db-sig is going to promote db-api from interface recommendations to framework. -haz From thierry@nekhem.com Tue Oct 1 12:57:12 2002 From: thierry@nekhem.com (thierry@nekhem.com) Date: Tue, 1 Oct 2002 13:57:12 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <200210010528.54909.hazmat@objectrealms.net>; from hazmat@objectrealms.net on Tue, Oct 01, 2002 at 05:28:54AM -0700 References: <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <200210010528.54909.hazmat@objectrealms.net> Message-ID: <20021001135712.A1699@musashi.wanadoo.fr> On Tue, Oct 01, 2002 at 05:28:54AM -0700, hazmat wrote: > On Tuesday 01 October 2002 03:21 am, Magnus Lycka wrote: > > At 10:45 2002-10-01 +0200, Jekabs Andrushaitis wrote: > > >I am not saying that [psycopg] is best, however my advice is > > >not to use Python module supplied with PostgreSQL sources... > > > > Why not? > > > > > > In general I don't mind diversity, but I four > > drivers for the same database seems a bit redundant. > > imho, i would only use pyscopg or pypgsql. of the four they are under the most > active development. Wrong! PoPy is continuing but slowly its development, exploring new ways to make the driver more powerful. I remind you that PoPy's development has begun in 2000, so adding quickly more and more features becomes difficult. When we began PoPy there was only pygresql. That's right, today there are too much drivers for postgresql, and the PoPy team is ready to merge its work w/ others teams like psycopg team, to have less drivers but more powerful, more featured and more stable! > > basically my deciding factor is whether i want to use libpq (pgsql c client > lib) or python db-api or if i want to use zope, if db-api i generally would > recommend pyscopg as it implements db-api compliance at the c level over > libpq. pypgsql is a c extension binding over libpq, with db-api interface > written in python. if zope, i would use psycopg as it has extensive testing > in that area, and converts to mxDateTimes to ZopeTimes. imho, the two > bindings serve different audiences. > > > Any chance that some of these will merge? We are already thinking about merging.. let others teams having the same way > > not likely. > > > After all, largely due to open source, we are > > going towards more and more of a component > > architecture in our software solutions, and we > > use different libraries and frameworks for different > > parts of the system. A library or framework that > > is built in python and use PostgreSQL might use > > any of these four drivers. > > not really, the limitations/bugs of some of the drivers will become apparent > quickly. > > > Thus, if we pick several of these components, that > > do different things, we might end up with several > > different and possibly conflicting database drivers > > for communication between Python and PostgreSQL. I > > haven't been bitten by this yet, but it seems a > > bit confusing to me... > > ideally their would be a driver framework with plugins, and we'd only have to > worry about the portability of our sql. as it is, most people implement their > own abstraction layer, as it does not seem apparent to me, that the db-sig is > going to promote db-api from interface recommendations to framework. > > -haz > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig Best regards, Thierry From fog@initd.org Tue Oct 1 13:22:52 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 14:22:52 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> References: <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> Message-ID: <1033474973.1096.231.camel@momo> --=-cfd711gBq+vhz5L9ERQ3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 12:21, Magnus Lycka ha scritto: > In general I don't mind diversity, but I four > drivers for the same database seems a bit redundant. >=20 > Any chance that some of these will merge? they are all basend on different concepts (apart from popy and psycopg that are quite similar), so i don't think there is space for a merge.=20 --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Viviamo in un mondo reale, Ciccio. -- Lucy --=-cfd711gBq+vhz5L9ERQ3 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mZOcvcCgrgZGjesRAi68AJ9DvhxAQELxgvK+7AOXnFFhW6JT3ACgpVf0 Fkz4SkSf8AcWBEdVM9+AmkA= =jkai -----END PGP SIGNATURE----- --=-cfd711gBq+vhz5L9ERQ3-- From magnus@thinkware.se Tue Oct 1 13:53:36 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 14:53:36 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033474973.1096.231.camel@momo> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> At 14:22 2002-10-01 +0200, Federico Di Gregorio wrote: >they are all basend on different concepts (apart from popy and psycopg >that are quite similar), so i don't think there is space for a merge. There seems to be space for one merge at least... :) Perhaps if you all wrap your clever head around this problem you will after all find ways to unite your efforts more? Maybe there are aspects in all modules that aren't really so central to the needs? Maybe some functionality can be offered as layers on top of the driver? Maybe one driver can be made that can be used in several different ways? It seems that there is a potential for gains for all involved if there is only one driver. (Or at least one dominating and recommended driver.) It's been a similar situation with Apache support, with mod_python, mod_snake and PyApache. I don't think it's good. Now mod_snake has been discontinued and mod_python has been made part of the Apache project. I think that is a good thing, and that it will increase the chances of being able to run python without all the CGI overhead in web hotels etc. I mean, I see mod_perl installed almost everywhere, and mod_python...never... Lets just hope mod_python will be a standard component in Red Hat etc... It's a better situation with PostgreSQL since it comes with Python support included. But it's a bit boring if the "default" alternative is the least good... --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@initd.org Tue Oct 1 14:01:34 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 15:01:34 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> Message-ID: <1033477294.1338.244.camel@momo> --=-e8JMkvQsho0n9QUkt/BM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 14:53, Magnus Lycka ha scritto: > At 14:22 2002-10-01 +0200, Federico Di Gregorio wrote: > >they are all basend on different concepts (apart from popy and psycopg > >that are quite similar), so i don't think there is space for a merge. >=20 > There seems to be space for one merge at least... :) >=20 > Perhaps if you all wrap your clever head around this > problem you will after all find ways to unite your > efforts more? Maybe there are aspects in all modules > that aren't really so central to the needs? Maybe > some functionality can be offered as layers on > top of the driver? Maybe one driver can be made > that can be used in several different ways? well,i can't say for sure but i'll present you an example. psycopg was built with multithreading in mind: every time it take a possible long operation that does not alter the internal state of the python interpreter it releases the global lock. every function was written around this concept. how much code will be reusable in other projects? how much difficult would be to merge? also, psycopg has a very sophisticated postgresql->python type casting mechanism and will be much less usefull to a lot of people without it. imo, the only possible merge is when one of the projects gets discontinued and the authors "merge" into another project. this is true not only for those projects but for every project that get started because the author feels others are pushing in the wrong direction..=20 --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -- D.E.Knuth --=-e8JMkvQsho0n9QUkt/BM Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mZyuvcCgrgZGjesRAuYnAJ9fzTgcNBMG0T0SIGJ5nV4jCXEhGwCfdSIP JbThXrr+RS4lzfBGodZ+k64= =BPyY -----END PGP SIGNATURE----- --=-e8JMkvQsho0n9QUkt/BM-- From haering_postgresql@gmx.de Tue Oct 1 14:20:43 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 1 Oct 2002 15:20:43 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> Message-ID: <20021001132042.GB631@lilith.ghaering.test> * Magnus Lycka [2002-09-30 23:21 +0200]: > Are there any good feature comparisions of > DB-API modules (not just for PostgreSQL) on > the web? Maybe it would be a good thing for > the Python Wiki http://www.python.org/cgi-bin/moinmoin/ > > I've seen (just checked :) > http://www.python.org/cgi-bin/moinmoin/ChoosingDatabase > but it would be nice to see something more of a table with > columns like > > name > rdbms > development status > licence > OS > Python versions > Quoting styles > thread support > extras > limitations > > Something like that... Easy one: http://www.python.org/cgi-bin/moinmoin/DbApiModuleComparison?action=show Fill in the gaps :-) -- Gerhard From magnus@thinkware.se Tue Oct 1 14:20:49 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 15:20:49 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <200210010528.54909.hazmat@objectrealms.net> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> At 05:28 2002-10-01 -0700, hazmat wrote: >imho, i would only use pyscopg or pypgsql. of the four they are under the= =20 >most >active development. It seems popy might merge with pyscopg? Is there a good reason why pyscopg or pypgsql can't become the standard driver which is included in the standard PostgreSQL database? What is so important with PyGreSQL if "everybody" thinks that it shouldn't be used? I wrote: > > A library or framework that > > is built in python and use PostgreSQL might use > > any of these four drivers. > >not really, the limitations/bugs of some of the drivers will become= apparent >quickly. Oh? Why does PyDO use PyGreSQL then? >ideally their would be a driver framework with plugins, and we'd only have= to >worry about the portability of our sql. as it is, most people implement= their >own abstraction layer, as it does not seem apparent to me, that the db-sig= is >going to promote db-api from interface recommendations to framework. I'm afraid you might be right. I have a feeling that this is somehow a consequence of how open source projects work. Those who are actually doing the real work of developing and maintaining database drivers are typically happy with what they have produced, and see few reasons to do things differently. Those (like me) who just want to _use_ the drivers in the most convenient way are typically to busy coding other stuff to really make a concrete impact on how the drivers work... It's not as if we pay the bills of the driver developers... Well, I shouldn't complain. Things are great really, and however much we improve stuff there will always be more things to complain over. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From haering_postgresql@gmx.de Tue Oct 1 14:30:00 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 1 Oct 2002 15:30:00 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033474973.1096.231.camel@momo> References: <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033474973.1096.231.camel@momo> Message-ID: <20021001133000.GC631@lilith.ghaering.test> * Federico Di Gregorio [2002-10-01 14:22 +0200]: > Il mar, 2002-10-01 alle 12:21, Magnus Lycka ha scritto: > > > In general I don't mind diversity, but I four > > drivers for the same database seems a bit redundant. > > > > Any chance that some of these will merge? > > they are all basend on different concepts (apart from popy and psycopg > that are quite similar), so i don't think there is space for a merge. Plus I believe the respective module authors have strong feelings about the licenses of their modules. pyPgSQL's authors (i. e. Bill Allie and me) want to keep it under a Python-style license, for example. Nothing new, just the usual problems of Open Source projects :-/ I also don't see that much room for cooperation, apart from perhaps a DB-API conformance test suite and a DB-API tutorial, which Federico started both once. One field I see room for cooperation is the implementation of PostgreSQL types in C or Python. pyPgSQL has many types mapped already, but the more obscure ones (lines, internet addresses, etc.) are still missing. Especially the parsing of PostgreSQL types is sometimes hairy, for example with ARRAYs. Due to the licenses, other module authors are free to help themselves with pyPgSQL code, but not necessarily the other way round ;-) -- Gerhard From hazmat@objectrealms.net Tue Oct 1 14:45:38 2002 From: hazmat@objectrealms.net (hazmat) Date: Tue, 1 Oct 2002 06:45:38 -0700 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <20021001135712.A1699@musashi.wanadoo.fr> References: <1033406964.1338.130.camel@momo> <200210010528.54909.hazmat@objectrealms.net> <20021001135712.A1699@musashi.wanadoo.fr> Message-ID: <200210010645.38602.hazmat@objectrealms.net> On Tuesday 01 October 2002 04:57 am, thierry@nekhem.com wrote: > On Tue, Oct 01, 2002 at 05:28:54AM -0700, hazmat wrote: > > On Tuesday 01 October 2002 03:21 am, Magnus Lycka wrote: > > > At 10:45 2002-10-01 +0200, Jekabs Andrushaitis wrote: > > > >I am not saying that [psycopg] is best, however my advice is > > > >not to use Python module supplied with PostgreSQL sources... > > > > > > Why not? > > > > > > > > > In general I don't mind diversity, but I four > > > drivers for the same database seems a bit redundant. > > > > imho, i would only use pyscopg or pypgsql. of the four they are under the > > most active development. > > Wrong! PoPy is continuing but slowly its development, exploring new ways > to make the driver more powerful. I remind you that PoPy's development > has begun in 2000, so adding quickly more and more features becomes > difficult. When we began PoPy there was only pygresql. That's right, > today there are too much drivers for postgresql, and the PoPy team is > ready to merge its work w/ others teams like psycopg team, to have less > drivers but more powerful, more featured and more stable! my apologies if i offended, but i wouldn't consider my statement wrong, as i said imho, those two drivers under the most active development. a statement which does not preclude development in the other drivers, just their degree. as the most recent release of popy was over a year ago, and the public cvs is unchanged in over a year, its not hard to see why such a distinction is easy to make. thank you for the history lesson. having just looked at the public cvs of popy, it appears that both pypgsql and psycopg offer more features, i'm curious of what benefit from a *code* perspective you think merging the codebases if feasible will bring. -haz From magnus@thinkware.se Tue Oct 1 14:51:38 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 15:51:38 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033477294.1338.244.camel@momo> References: <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001151942.029cdeb8@www.thinkware.se> At 15:01 2002-10-01 +0200, Federico Di Gregorio wrote: >imo, the only possible merge is when one of the projects gets >discontinued and the authors "merge" into another project. this is true >not only for those projects but for every project that get started >because the author feels others are pushing in the wrong direction.. You might be true. At least I think the "ultimate" python postgresql driver will to 90-95% be based on code from *one* of the projects. After all, all four drivers are reasonably complete today as far as I understand. But code reuse is not everything. Ideas, experience goals, documentaion and APIs can be reused as well. I think the main benefit will be that more people be working on one project. (If there is work for more people...) There will also be future development, as the DB-API might change, PostgreSQL will change, a uniform exception standard might develop, maybe even a uniform framework. Wouldn't it be nice if this work didn't have to be done four times for PostgreSQL? What might be worth keeping is API compatibility, so that users don't suddenly have to make major changes in the code that uses the drivers. But if the drivers are DB-API 2 compatible, this might not be so difficult? Would it be very hard to change psycopg so that python programs written for the other drivers (in DB-API 2 mode) would work with psycopg? Would it be more work to fix this than to continue working on separate projects. I realize that the driver included with PostgreSQL has an older incompatible API as well. I guess the old driver could be bundled with PostgreSQL to provide that interface. Considering that the DB-API 2 has been around for more than three years, it's a bit surprising to me that the old API hasn't been deprecated in the PostgreSQL docs. Those docs rather suggest using the ancient API by giving full documentation for that, and completely ignoring the new, referring only to the DB API spec and a very brief tutorial that uses Solid DB... --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@initd.org Tue Oct 1 14:52:22 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 15:52:22 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001151942.029cdeb8@www.thinkware.se> References: <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001144103.029a2890@www.thinkware.se> <5.1.0.14.0.20021001151942.029cdeb8@www.thinkware.se> Message-ID: <1033480342.1338.260.camel@momo> --=-CkmmbB1klK4ArbDrcVrh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 15:51, Magnus Lycka ha scritto: > Would it be very hard to change psycopg so that > python programs written for the other drivers > (in DB-API 2 mode) would work with psycopg? python prorams work, at least if you don't expect timestamps to be returned as strings and NULL values to be returned as "". if this is the case psycopg won't work with your old code.. :( =20 --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Lord, defend me from my friends; I can account for my enemies. -- Charles D'Hericault --=-CkmmbB1klK4ArbDrcVrh Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9maiWvcCgrgZGjesRAr0mAKDT+f/KFm3aVEHqz5Ow2XLNvAsNbQCfSSPx wORKH3AIpCEtOorshlQe7Sw= =niav -----END PGP SIGNATURE----- --=-CkmmbB1klK4ArbDrcVrh-- From hazmat@objectrealms.net Tue Oct 1 15:39:04 2002 From: hazmat@objectrealms.net (hazmat) Date: Tue, 1 Oct 2002 07:39:04 -0700 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> Message-ID: <200210010739.04616.hazmat@objectrealms.net> On Tuesday 01 October 2002 06:20 am, Magnus Lycka wrote: > At 05:28 2002-10-01 -0700, hazmat wrote: > >imho, i would only use pyscopg or pypgsql. of the four they are under the > >most > >active development. > > It seems popy might merge with pyscopg? i'm interested, as user, in hearing of any benefits that this merger would bring from a code/technical perspective. i haven't heard any yet. open source brings choices, and thats not nesc. a bad thing. > > Is there a good reason why pyscopg or pypgsql can't > become the standard driver which is included in > the standard PostgreSQL database? open source also brings community politics. pygresql is the oldest python binding to postgres, and its developer is also a postgres developer. so when the postgres community was deciding to include a language binding.... although to be honest i can't recall if other bindings were stable when pygre became bundled with postgres. >What is so important > with PyGreSQL if "everybody" thinks that it shouldn't > be used? several things, when i last used pygresql a couple of years ago, i found its db-api interface to be horribly broken. i believer there have been some fixes to this, in the interim *years*. perhaps most signifigantly from my own perspective is that it plays *very* poorly with zope. to wrt, datetime conversions, and the fact that its zope adapter executed queries serially (which is not nesc. the fault of pygresql) . probably one of the authors/developers of the alternative frameworks, could better answer on why they wanted to develop a new framework, rather than using/extending/fixing pygresql. or perhaps their time is better spent coding ;-) > > I wrote: > > > A library or framework that > > > is built in python and use PostgreSQL might use > > > any of these four drivers. > > > >not really, the limitations/bugs of some of the drivers will become > > apparent quickly. > > Oh? Why does PyDO use PyGreSQL then? i can't speak to why pydo uses pygresql, but there are a couple of reasons why other projects use pygresql, imo. the biggest one is ease of distribution, as pygresql comes with postgres. another one is sometimes developers are not aware of the better alternatives > >ideally their would be a driver framework with plugins, and we'd only have > > to worry about the portability of our sql. as it is, most people > > implement their own abstraction layer, as it does not seem apparent to > > me, that the db-sig is going to promote db-api from interface > > recommendations to framework. > > I'm afraid you might be right. > > I have a feeling that this is somehow a consequence > of how open source projects work. > Those who are actually doing the real work of > developing and maintaining database drivers are > typically happy with what they have produced, > and see few reasons to do things differently. well the db-sig decided not to make a driver interface frameworks to help developers in writing adapters according to a more lenient specification. > Those (like me) who just want to use the drivers > in the most convenient way are typically to busy > coding other stuff to really make a concrete impact > on how the drivers work... It's not as if we pay > the bills of the driver developers... > > Well, I shouldn't complain. Things are great really, > and however much we improve stuff there will always > be more things to complain over. well one of the consequences of open source, is you get to scratch your own itches ;-) -haz From haering_postgresql@gmx.de Tue Oct 1 15:01:02 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 1 Oct 2002 16:01:02 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <1033406964.1338.130.camel@momo> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> Message-ID: <20021001140102.GD631@lilith.ghaering.test> * Magnus Lycka [2002-10-01 15:20 +0200]: > At 05:28 2002-10-01 -0700, hazmat wrote: > >imho, i would only use pyscopg or pypgsql. of the four they are under the > >most > >active development. > > It seems popy might merge with pyscopg? > > Is there a good reason why pyscopg or pypgsql can't become the > standard driver which is included in the standard PostgreSQL database? Being in the PostgreSQL tree could IMO mean that development speed will be slowed down, because you need to be more careful in the context of PostgreSQL release cycles, for example. I could be mistaken, though. The plus, as currently seen with PyGreSQL, is that you get many more testers and PostgreSQL developers normally not concerned with Python will help, too, if there are bugs or problems. Well, maybe I should just send one gigantic patch to replace PyGreSQL with pyPgSQL ;-) > What is so important with PyGreSQL if "everybody" thinks that it > shouldn't be used? I for one found it took too long for well-known bugs to get fixed: http://archives.postgresql.org/pgsql-hackers/2001-10/msg00489.php This was at the time I still provided win32 binaries of PyGreSQL and I got a bug report from a win32 user. It turned out that the bug was well-known for over a year (!). And it wasn't terribly difficult to find, either. And I've read that even a patch was sent to the mailing list well before. So I just bypassed the official maintainer and sent my patch to the PostgreSQL developers. This resulted in quite an interesting discussion, which also briefly touched the issue PyGreSQl vs. other Python projects: http://archives.postgresql.org/pgsql-patches/2001-08/msg00201.php http://archives.postgresql.org/pgsql-patches/2001-08/thrd2.php Especially one guy from Redhat was quite pleased, as he got reports about this bug from his supported customers before :-) -- Gerhard From magnus@thinkware.se Tue Oct 1 15:08:48 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 16:08:48 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <20021001132042.GB631@lilith.ghaering.test> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> At 15:20 2002-10-01 +0200, Gerhard H=E4ring wrote: >Easy one: >http://www.python.org/cgi-bin/moinmoin/DbApiModuleComparison?action=3Dshow Ok, that's a start...I was more wondering if it was done already... What do I see... psycopg ... GPL I suppose that means that applications that import that module will be GPL as well... In general I really like GPL, unfortunately I sometimes rely on customers that want to own the code I build for them... This makes GPL an impossible choice in those situations. (Just as PyDO etc.) Is this your intention Federico, that people should only be able to build open source software if they use psycopg? You have no intention of using LGPL etc? Personally I think it's very different to use GPL for a complete application such as a web browser or an editor than to use it for a library that is destined to be just a small part in large system. --=20 Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From gerhard.haering@gmx.de Tue Oct 1 15:17:43 2002 From: gerhard.haering@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 1 Oct 2002 16:17:43 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> Message-ID: <20021001141743.GB733@lilith.ghaering.test> * Magnus Lycka [2002-10-01 16:08 +0200]: > At 15:20 2002-10-01 +0200, Gerhard Häring wrote: > >Easy one: > >http://www.python.org/cgi-bin/moinmoin/DbApiModuleComparison?action=show > > Ok, that's a start...I was more wondering if > it was done already... > > What do I see... > psycopg ... GPL > > I suppose that means that applications that import > that module will be GPL as well... They need to have a GPL compatible license if you distribute them outside your organisation. You can see a list of known such licenses on the FSF pages. > In general I really like GPL, unfortunately I sometimes rely on > customers that want to own the code I build for them... This makes GPL > an impossible choice in those situations. Perhaps you can get a special deal with Federico ;-) (But I personally am not sure that what works for something as large as Qt as a business strategy will work for a Python database adapter as well.) Thinking of which, one other thing we might add to the comparison table is wether commercial support is available. As far as I remember, only mxODBC and the Sybase module have, right? -- Gerhard From fog@initd.org Tue Oct 1 15:30:01 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 16:30:01 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> Message-ID: <1033482601.1338.282.camel@momo> --=-wJCfoaeeqUvLOPMYmfc0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 16:08, Magnus Lycka ha scritto: > At 15:20 2002-10-01 +0200, Gerhard H=E4ring wrote: > >Easy one: > >http://www.python.org/cgi-bin/moinmoin/DbApiModuleComparison?action=3Dsh= ow >=20 > Ok, that's a start...I was more wondering if > it was done already... >=20 > What do I see... > psycopg ... GPL >=20 > I suppose that means that applications that import > that module will be GPL as well... well, no. you're not directly linking to it, python does and python license is GPL-compatible. then you call psycopg *through* python using a well defined api, so your code can be anything. this is an edge case, but my interpretation is that as long as: 1/ you don't use psycopg code without python, by linking directly into your app; and 2/ you release modifications to psycopg you should be ok. this is just an interpretation, i hope FSF will clarify this dark corner in a future version of the GPL. > Is this your intention Federico, that people should only > be able to build open source software if they use psycopg? for work i do programming and consulting, using almost only free software. my way to give back to the community that helps me pay my rent and food is to release all my code under a free license. i hope others do the same, but if they don't, then let's have them pay for it.=20 (to be read: if you want to develop a proprietary product using psycopg and the above interpretation of the GPL does not satisfy you, pay me enough and i'll change the license :) --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Spesso crescere ed andare a vivere da soli =E8 l'unico modo di restare bambini. -- Alice Fontana --=-wJCfoaeeqUvLOPMYmfc0 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mbFpvcCgrgZGjesRApzLAJ9jdr2ZprDsJHToTEATwrch8jnCSACgqkK7 dx+kjZQqpsQnvQ2vYnalivs= =GxOh -----END PGP SIGNATURE----- --=-wJCfoaeeqUvLOPMYmfc0-- From magnus@thinkware.se Tue Oct 1 15:34:12 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 16:34:12 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <200210010739.04616.hazmat@objectrealms.net> References: <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001162329.029c5270@www.thinkware.se> At 07:39 2002-10-01 -0700, hazmat wrote: >i'm interested, as user, in hearing of any benefits that this merger would >bring from a code/technical perspective. i haven't heard any yet. The merged driver would have more users and more developers. This could lead to faster development and better testing. There are also other aspects than code quality. You touch it yourself below in your answer about PyDO. >open source brings choices, and thats not nesc. a bad thing. No, but the more the merrier isn't always true either. (I'm not by mistake on a Perl mailing list, am I? ;) > >What is so important > > with PyGreSQL if "everybody" thinks that it shouldn't > > be used? > >several things, when i last used pygresql a couple of years ago, i found its >db-api interface to be horribly broken. i believer there have been some fixes >to this, in the interim *years*. perhaps most signifigantly from my own >perspective is that it plays *very* poorly with zope. to wrt, datetime >conversions, and the fact that its zope adapter executed queries serially >(which is not nesc. the fault of pygresql) . Ok... Then it seems that it's not so important to keep it around? > > Oh? Why does PyDO use PyGreSQL then? > >i can't speak to why pydo uses pygresql, but there are a couple of reasons >why >other projects use pygresql, imo. the biggest one is ease of distribution, as >pygresql comes with postgres. another one is sometimes developers are not >aware of the better alternatives Just what I thought... Wouldn't it then be better if PyGreSQL was replaced with one of the other drivers then? Both good code, less confusion for developers and ease of distribution. (A merge sounds less hostile than a takeover though...) -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From magnus@thinkware.se Tue Oct 1 15:36:36 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 16:36:36 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <20021001141743.GB733@lilith.ghaering.test> References: <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001163608.029d6138@www.thinkware.se> At 16:17 2002-10-01 +0200, Gerhard H=E4ring wrote: >Thinking of which, one other thing we might add to the comparison table >is wether commercial support is available. As far as I remember, only >mxODBC and the Sybase module have, right? In the "extras" column? (The table is wide enough...) --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@initd.org Tue Oct 1 15:21:58 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 16:21:58 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <200210010739.04616.hazmat@objectrealms.net> References: <5.1.0.14.0.20021001114812.02975688@www.thinkware.se> <5.1.0.14.0.20021001145348.029c5040@www.thinkware.se> <200210010739.04616.hazmat@objectrealms.net> Message-ID: <1033482118.1338.274.camel@momo> --=-YuM9bgGeZl3yYrq1l7sD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 16:39, hazmat ha scritto: > probably one of the authors/developers of the alternative frameworks, cou= ld=20 > better answer on why they wanted to develop a new framework, rather than=20 > using/extending/fixing pygresql. or perhaps their time is better spent co= ding some history, for the interested parties..=20 about 3 years ago i was working in mixad live, togheter with thierry (PoPy's author) and we were very displeased by pygresql: no dbapi support, a lot of zope malfunctions/locks, bad typecasting, etc. i begun looking at the code and i found it.. well, it did not suited my taste. i think thierry tought the same thing an proposed to write a new adapter. at that time i had not the time to help him coding, so i just did cvs and release maintenance, little patch integration and such. after PoPy 1.0 was released we begun discussion PoPy II (PoPy had some serious design flaws, imo) and then our company splitted and thierry went working/founding nekhem. we (me and michele) started to write what we always named PoPy II, just changing its name to not "override" thierry's project.. =20 anyway, i don't remember exactly why i found pygresql code so terrible at that time. i just remember that after an 8h dive into the source tree i tought "was a mess, much better redo it from scratch." maybe we (me and pygresql author) just had very different programming habits.. :) --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Spesso crescere ed andare a vivere da soli =E8 l'unico modo di restare bambini. -- Alice Fontana --=-YuM9bgGeZl3yYrq1l7sD Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9ma+GvcCgrgZGjesRAvyDAKCKtFJGxPMCKxB+2TTaQ190vZ/PtQCeNowM BoHWYbVYkS95fRRaO2olFyY= =bC9V -----END PGP SIGNATURE----- --=-YuM9bgGeZl3yYrq1l7sD-- From haering_postgresql@gmx.de Tue Oct 1 16:05:30 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 1 Oct 2002 17:05:30 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033482601.1338.282.camel@momo> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <1033482601.1338.282.camel@momo> Message-ID: <20021001150530.GA1506@lilith.ghaering.test> * Federico Di Gregorio [2002-10-01 16:30 +0200]: > Il mar, 2002-10-01 alle 16:08, Magnus Lycka ha scritto: > > [psycopg is licensed under the GPL] > > I suppose that means that applications that import > > that module will be GPL as well... > > well, no. you're not directly linking to it, python does and python > license is GPL-compatible. then you call psycopg *through* python using > a well defined api, so your code can be anything. this is an edge case, > but my interpretation is that as long as: > > 1/ you don't use psycopg code without python, by linking > directly into your app; and > 2/ you release modifications to psycopg > > you should be ok. this is just an interpretation, i hope FSF will > clarify this dark corner in a future version of the GPL. Hey, cool. This was my interpretation, too. What made me a little unsure is that I haven't seen this interpretation anywhere else. At least until today. -- Gerhard From fog@initd.org Tue Oct 1 16:34:11 2002 From: fog@initd.org (Federico Di Gregorio) Date: 01 Oct 2002 17:34:11 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <20021001141743.GB733@lilith.ghaering.test> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <20021001141743.GB733@lilith.ghaering.test> Message-ID: <1033486452.1338.294.camel@momo> --=-52fIV6f9TgnRgtb2116L Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il mar, 2002-10-01 alle 16:17, Gerhard H=E4ring ha scritto: > Perhaps you can get a special deal with Federico ;-) (But I personally > am not sure that what works for something as large as Qt as a business > strategy will work for a Python database adapter as well.) this does not belong really to this ML, anyway..=20 it just won't work for a little project as psycopg. but remember, selling "alternative licenses" for psycopg is not my business model. it just makes me feel right and helps rebalancing the proprietary vs free "war": if you release code you don't have to pay for anything. if you don't release code, at least pay for others (me) doing it. that's all. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-52fIV6f9TgnRgtb2116L Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mcBzvcCgrgZGjesRAhRQAJ4jj00aOF3oigiOjNFdL90VuTfmnwCfR2ej 7qX9C7x9rCIxfA10L+OX5pI= =c6ML -----END PGP SIGNATURE----- --=-52fIV6f9TgnRgtb2116L-- From mal@lemburg.com Tue Oct 1 16:53:22 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 01 Oct 2002 17:53:22 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <1033482601.1338.282.camel@momo> <20021001150530.GA1506@lilith.ghaering.test> Message-ID: <3D99C4F2.5010904@lemburg.com> Gerhard H=E4ring wrote: > * Federico Di Gregorio [2002-10-01 16:30 +0200]: >=20 >>Il mar, 2002-10-01 alle 16:08, Magnus Lycka ha scritto: >> >>>[psycopg is licensed under the GPL] >>>I suppose that means that applications that import >>>that module will be GPL as well... >> >>well, no. you're not directly linking to it, python does and python >>license is GPL-compatible. then you call psycopg *through* python using >>a well defined api, so your code can be anything. this is an edge case, >>but my interpretation is that as long as: >> >> 1/ you don't use psycopg code without python, by linking >> directly into your app; and >> 2/ you release modifications to psycopg >> >>you should be ok. this is just an interpretation, i hope FSF will >>clarify this dark corner in a future version of the GPL. >=20 >=20 > Hey, cool. This was my interpretation, too. What made me a little unsur= e > is that I haven't seen this interpretation anywhere else. At least unti= l > today. Probably because it's likely not to work out in court :-) Note that the GPL is only important if you want to redistribute whatever code you write against the GPLed piece of the application. Only in that case you are forced to ship the source code to whoever wants to take a look. Placing a non-GPLed piece of code between the rest of your application and the GPLed part doesn't secure your application from the GPL: you are forming a new complete work and that's what the GPL applies to if you redistribute the work to someone else. It doesn't matter whether you are linking, loading byte code or simply using GPLed static data in your application. The only safe way to deal with this is to stick to LGPLed libaries. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From magnus@thinkware.se Tue Oct 1 22:00:33 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 23:00:33 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <1033482601.1338.282.camel@momo> References: <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> Message-ID: <5.1.0.14.0.20021001223759.029a2c48@www.thinkware.se> At 16:30 2002-10-01 +0200, Federico Di Gregorio wrote: >well, no. you're not directly linking to it, python does and python >license is GPL-compatible. I guess the GPL is fairly C-centric. I've always assumed "import module" equates to linking. >you should be ok. this is just an interpretation, i hope FSF will >clarify this dark corner in a future version of the GPL. I that case, what would be the difference between GPL and LGPL? None if you use python, but substancial if you use C? > > Is this your intention Federico, that people should only > > be able to build open source software if they use psycopg? > >for work i do programming and consulting, using almost only free >software. my way to give back to the community that helps me pay my rent >and food is to release all my code under a free license. i hope others >do the same, but if they don't, then let's have them pay for it. No it sounds that you are backing out of your claim that psycopg can be used freely with commercially licenced programs. Which is it? >(to be read: if you want to develop a proprietary product using psycopg >and the above interpretation of the GPL does not satisfy you, pay me >enough and i'll change the license :) I won't pay you. Maybe a customer of mine? If I can, I also use free licences. So far I typically get paid by the hour, and I survive on that. I don't sell software products. Actually, my current client is considering an open source licence for the current project, but he hasn't quite made up his mind. IF we had used PostgreSQL for that, and IF I had said that the best driver forces him to release his software as Open Source if he uses it, I feel pretty sure he would have requested that I use something else. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From magnus@thinkware.se Tue Oct 1 22:23:06 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 01 Oct 2002 23:23:06 +0200 Subject: [DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL In-Reply-To: <3D99C4F2.5010904@lemburg.com> References: <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20020930231112.02902848@www.thinkware.se> <5.1.0.14.0.20021001155425.029d3170@www.thinkware.se> <1033482601.1338.282.camel@momo> <20021001150530.GA1506@lilith.ghaering.test> Message-ID: <5.1.0.14.0.20021001230250.028f7ea0@www.thinkware.se> At 17:53 2002-10-01 +0200, M.-A. Lemburg wrote: >Note that the GPL is only important if you want to redistribute >whatever code you write against the GPLed piece of the application. An important point, but... * I've had customers who we're so sure that their custom version of a system would be so much better than the standard product that they paid us extra to get a share in the profits if we resold their version to other customers. (Never happened of course.) Would they have accepted GPL? No way! (Actually it was a municipality!) * You never know where the software you build for a certain purpose ends up, or what it transforms to after some years. A lot of software which is sold today was initally developed for internal use... The consequences of using GPL *might* be more far reaching than you think... >Only in that case you are forced to ship the source code >to whoever wants to take a look. Placing a non-GPLed piece >of code between the rest of your application and the GPLed >part doesn't secure your application from the GPL: you are >forming a new complete work and that's what the GPL applies >to if you redistribute the work to someone else. It doesn't >matter whether you are linking, loading byte code or simply >using GPLed static data in your application. > >The only safe way to deal with this is to stick to LGPLed >libaries. Or MIT / BSD / Python etc... This has always been my interpretation also. But it's tricky. CherryPy (www.cherrypy.org) is GPL. It copies parts of itself into the generated code it creates. (It's a neat tool for building web sites.) The author of CherryPy states very clearly that his intention is NOT that the web sites developed with cherrypy should be covered by GPL. He just don't want anyone to create a commercial version of CherryPy. I'm not sure the licence he uses reflects his wishes though... And one day, in the future, what Remi stated in 2002 might not be of much value. Someone else might be the copyright holder by then, and interpret the GPL differently. In other words, these licence issues are difficult for the software writers, as well as for the software users... Way-off-topic-but-it-concerns-us-ly yours, Magnus -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@initd.org Wed Oct 2 00:19:42 2002 From: fog@initd.org (Federico Di Gregorio) Date: 02 Oct 2002 01:19:42 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <3D9A1BD9.8030005@devis.com> References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> Message-ID: <1033514382.1338.324.camel@momo> --=-3C4EnE2g36VJ7Q+jsoMz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mer, 2002-10-02 alle 00:04, Tom Jenkins ha scritto: > I have read these and I don't believe the GPL fits the stated goal of=20 > Federico. > From why-not-lgpl > "The GNU Project has two principal licenses to use for libraries. One is=20 > the GNU Library GPL; the other is the ordinary GNU GPL. The choice of=20 > license makes a big difference: using the Library GPL permits use of the=20 > library in proprietary programs; using the ordinary GPL for a library=20 > makes it available only for free programs. let's restate the problem: bash is GPL'ed. should *any* sh script be released under the GPL? or only the ones using bash extensions to standard bourne shell? and why is python (and its extension psycopg) diferent from a shell? the only problem i can forsee is people mixing GPL'ed and proprietary modules written in C in the same python, but still then, they are independently linking with python (unless the proprietary module call the GPL'ed one). --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org I came like Water, and like Wind I go. -- Omar Khayam --=-3C4EnE2g36VJ7Q+jsoMz Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mi2OvcCgrgZGjesRAnguAJ9Uu3L43WlDgZcxPfHEJOuVvHvXFwCgy+eU 8YYYHTL5gf6CdOIM1SRY9MU= =kNes -----END PGP SIGNATURE----- --=-3C4EnE2g36VJ7Q+jsoMz-- From magnus@thinkware.se Wed Oct 2 07:52:22 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Wed, 02 Oct 2002 08:52:22 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <1033514382.1338.324.camel@momo> References: <3D9A1BD9.8030005@devis.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> Message-ID: <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> At 01:19 2002-10-02 +0200, Federico Di Gregorio wrote: >let's restate the problem: bash is GPL'ed. should *any* sh script be >released under the GPL? or only the ones using bash extensions to >standard bourne shell? and why is python (and its extension psycopg) >diferent from a shell? Do you suggest that a python program that is written for vanilla DB-API 2 and happens to work with psycopg could be proprietary, but a python program that uses unique features in psycopg can not? The issue is (I suppose) whether the python program is a derivate work of psycopg. I don't think there is any doubt that python code that uses unique features of psycopg must be considered a derivate work, just as a novel about the hobbit Frodo is a derivate work of Tolkiens books, and thus a copyright infringement if published without permission. But is it enough with "import psycopg" to make it a derivate work if the rest of the code is generic DB API2 code? --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From haering_postgresql@gmx.de Wed Oct 2 08:07:06 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 2 Oct 2002 09:07:06 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> References: <3D9A1BD9.8030005@devis.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> Message-ID: <20021002070706.GA1005@lilith.ghaering.test> * Magnus Lycka [2002-10-02 08:52 +0200]: > At 01:19 2002-10-02 +0200, Federico Di Gregorio wrote: > >let's restate the problem: bash is GPL'ed. should *any* sh script be > >released under the GPL? or only the ones using bash extensions to > >standard bourne shell? and why is python (and its extension psycopg) > >diferent from a shell? > > Do you suggest that a python program that is written for vanilla > DB-API 2 and happens to work with psycopg could be proprietary, but a > python program that uses unique features in psycopg can not? In Python, you're always coding against an interface, never directly linking against an implementation. If there is a module in the search path that you can import under a name not entirely unlike an existing GPLed module, that's certainly not my problem, right? You can make the usage of the interface more explicit, like with: MODNAME = "psycopg" mod = __import__(MODNAME) con = getattr(mod, "connect") apply(con, ...) but this is really just the same as: import psycopg con = psycopg.connect(...) But you're still only using an interface with certain names and parameter conventions. -- Gerhard From fog@initd.org Wed Oct 2 08:15:00 2002 From: fog@initd.org (Federico Di Gregorio) Date: 02 Oct 2002 09:15:00 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> References: <3D9A1BD9.8030005@devis.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> Message-ID: <1033542901.1338.843.camel@momo> --=-YfPj0I2z+M6oo2aRvXfN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mer, 2002-10-02 alle 08:52, Magnus Lycka ha scritto: > At 01:19 2002-10-02 +0200, Federico Di Gregorio wrote: > >let's restate the problem: bash is GPL'ed. should *any* sh script be > >released under the GPL? or only the ones using bash extensions to > >standard bourne shell? and why is python (and its extension psycopg) > >diferent from a shell? >=20 > Do you suggest that a python program that is written > for vanilla DB-API 2 and happens to work with psycopg > could be proprietary, but a python program that uses > unique features in psycopg can not? >=20 > The issue is (I suppose) whether the python program > is a derivate work of psycopg. is the following script a derivative work of bash and should then be placed under GPL? #!/bin/bash pushd /tmp && popd > I don't think there is any doubt that python code that > uses unique features of psycopg must be considered a > derivate work, just as a novel about the hobbit Frodo > is a derivate work of Tolkiens books, and thus a > copyright infringement if published without permission. i think there are *big* doubts. python bytecode and the (possibly dynamically linked) python executable are on different domains. nobody really thinks a single, proprietary bash script breaks bash license. now, tell me *where* python is different from bash. your program bytecode *uses* psycopg, it does not link with it. not even on "import", import just instructs the python interpreter to link itself agains some code. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org All programmers are optimists. -- Frederick P. Brooks, Jr. --=-YfPj0I2z+M6oo2aRvXfN Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mpz0vcCgrgZGjesRAnfnAKC/tm+f5g6pjUmYAieBSKNviDxmAQCgx7Eq yGg7ez3ocGaZO6sktPoAnZc= =eQ5E -----END PGP SIGNATURE----- --=-YfPj0I2z+M6oo2aRvXfN-- From mal@lemburg.com Wed Oct 2 09:25:16 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 02 Oct 2002 10:25:16 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> Message-ID: <3D9AAD6C.3030004@lemburg.com> Federico Di Gregorio wrote: > Il mer, 2002-10-02 alle 00:04, Tom Jenkins ha scritto: > > >>I have read these and I don't believe the GPL fits the stated goal of >>Federico. >> From why-not-lgpl >>"The GNU Project has two principal licenses to use for libraries. One is >>the GNU Library GPL; the other is the ordinary GNU GPL. The choice of >>license makes a big difference: using the Library GPL permits use of the >>library in proprietary programs; using the ordinary GPL for a library >>makes it available only for free programs. > > > let's restate the problem: bash is GPL'ed. should *any* sh script be > released under the GPL? bash happens to be part of the OS, so it triggers the special LGPL like clause in the GPL which excludes software using OS facilities from the GPL restrictions. > or only the ones using bash extensions to > standard bourne shell? and why is python (and its extension psycopg) > diferent from a shell? > > the only problem i can forsee is people mixing GPL'ed and proprietary > modules written in C in the same python, but still then, they are > independently linking with python (unless the proprietary module call > the GPL'ed one). Please see my other reply. It doesn't matter which method of "combining" the GPLed work and your work is chosen. The GPL always applies to the work as a whole. Now, back to the topic: A Python database extension released under the GPL will only be usable in applications under the terms and conditions of the GPL, i.e. if you want to distribute the application to third parties, you have to ship it with complete source code. Note that this can be used (and is used) as business model: if a customer wants to build a closed source application around the GPLed database module, the customer would have to license the database module from the author under different licensing terms. Of course, this only works if you can identify the copyright holder -- depending on how the GPLed project is managed, this can be difficult. OTOH, if the idea is not to use the GPL as business model, you might as well switch to the LGPL and thereby reach out to a larger user base. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From fog@initd.org Wed Oct 2 09:37:24 2002 From: fog@initd.org (Federico Di Gregorio) Date: 02 Oct 2002 10:37:24 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <3D9AAD6C.3030004@lemburg.com> References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> Message-ID: <1033547845.1338.851.camel@momo> --=-5dFxehuvAWj/8EbpcAyJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mer, 2002-10-02 alle 10:25, M.-A. Lemburg ha scritto: > Federico Di Gregorio wrote: > > let's restate the problem: bash is GPL'ed. should *any* sh script be > > released under the GPL?=20 >=20 > bash happens to be part of the OS, so it triggers the special > LGPL like clause in the GPL which excludes software using > OS facilities from the GPL restrictions. so let's take another example: Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 72 those lines gets *interpreted* by emacs (i.e., it generate instructions to drive a process, something very similar to python bytecode, isn't it?) then *any* file incorporating instructions for emacs should be released under the GPL? and don't say emacs triggers the "part of the OS" clause, please. (ok, ok.. i know.. emacs is an OS by itself, but no jokes.. :) --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Nessuno dice che non si possa sognare in dettaglio, essere realistici e magari realizzarlo pure, il sogno. -- --=-5dFxehuvAWj/8EbpcAyJ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mrBEvcCgrgZGjesRAlvJAJ9ZELDk2hKTCmzHY9ZYa3vWNUoD2gCbBoPz ubwN9ZTYALYUrnltr3boZU4= =Kq3W -----END PGP SIGNATURE----- --=-5dFxehuvAWj/8EbpcAyJ-- From magnus@thinkware.se Wed Oct 2 10:10:34 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Wed, 02 Oct 2002 11:10:34 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <1033542901.1338.843.camel@momo> References: <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> <3D9A1BD9.8030005@devis.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> Message-ID: <5.1.0.14.0.20021002094712.02b17d98@www.thinkware.se> At 09:15 2002-10-02 +0200, Federico Di Gregorio wrote: >i think there are *big* doubts. python bytecode and the (possibly >dynamically linked) python executable are on different domains. nobody >really thinks a single, proprietary bash script breaks bash license. >now, tell me *where* python is different from bash. your program >bytecode *uses* psycopg, it does not link with it. not even on "import", >import just instructs the python interpreter to link itself agains some >code. I understand your position. The GPL claims that it covers any program that is a modified version of a GPLed program. One can certiainly claim that importing psycopg is not the same as modifying it, that the python program in question _uses_ psycopg, not that it is a modified version of it. But this is what the GPL FAQ says at: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation What is the difference between "mere aggregation" and "combining two modules into one program"? Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program. Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them. What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program." My suggestion for people who wants to use a GPL product like psycopg or cherrpy in proprietary software to ask the copyright holder for permission, and be careful if they don't get one. You might end up in a situation where the copyright holder of the GPL program claims that you violate his license and that you must stop using his software. I'm not suggesting that any specific person would do so. But you don't know for sure who owns a certain copyright a year from now... I guess an ammendment to the psycopg licence text could clean up things, Something like: "Importing and using the psycopg module from a python program is not considered to imply combining psycopg with the importing program. In other words, python programs using psycopg may use other licences than GPL." -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From gerhard.haering@opus-gmbh.net Wed Oct 2 10:14:42 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 2 Oct 2002 11:14:42 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <5.1.0.14.0.20021002094712.02b17d98@www.thinkware.se> References: <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> <3D9A1BD9.8030005@devis.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <5.1.0.14.0.20021002080430.02aebdf0@www.thinkware.se> <5.1.0.14.0.20021002094712.02b17d98@www.thinkware.se> Message-ID: <20021002091442.GA2096@HAERING> * Magnus Lycka [2002-10-02 11:10 +0200]: > [how the GPL applies in the context of Python modules] > I guess an ammendment to the psycopg licence text could clean > up things, Something like: > > "Importing and using the psycopg module from a python program is not > considered to imply combining psycopg with the importing program. In other > words, python programs using psycopg may use other licences than GPL." Btw. such a clarification is not without precendence. GNAT's runtime library (GNARL) and GUILE have ammendements that read very similar. -- Gerhard Häring OPUS GmbH München Tel.: +49 89 - 889 49 7 - 32 http://www.opus-gmbh.net/ From mal@lemburg.com Wed Oct 2 10:25:39 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 02 Oct 2002 11:25:39 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> <1033547845.1338.851.camel@momo> Message-ID: <3D9ABB93.6010901@lemburg.com> Federico Di Gregorio wrote: > Il mer, 2002-10-02 alle 10:25, M.-A. Lemburg ha scritto: > >>Federico Di Gregorio wrote: > > >>>let's restate the problem: bash is GPL'ed. should *any* sh script be >>>released under the GPL? >> >>bash happens to be part of the OS, so it triggers the special >>LGPL like clause in the GPL which excludes software using >>OS facilities from the GPL restrictions. > > > so let's take another example: > > Local Variables: > mode: indented-text > indent-tabs-mode: nil > sentence-end-double-space: t > fill-column: 72 > > those lines gets *interpreted* by emacs (i.e., it generate instructions > to drive a process, something very similar to python bytecode, isn't > it?) > > then *any* file incorporating instructions for emacs should be released > under the GPL? and don't say emacs triggers the "part of the OS" clause, > please. (ok, ok.. i know.. emacs is an OS by itself, but no jokes.. :) Input and output of GPLed programs are not automatically covered by the GPL, e.g. the GNU C compiler needs many instructions to tell it what to do with the code, but that doesn't make the code automatically fall under the GPL. Please read clause 0. of the GPL and the FAQ for details. http://www.gnu.org/licenses/gpl.html http://www.gnu.org/licenses/gpl-faq.html -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From magnus@thinkware.se Wed Oct 2 10:31:52 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Wed, 02 Oct 2002 11:31:52 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <1033547845.1338.851.camel@momo> References: <3D9AAD6C.3030004@lemburg.com> <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> Message-ID: <5.1.0.14.0.20021002111256.02b36f40@www.thinkware.se> At 10:37 2002-10-02 +0200, Federico Di Gregorio wrote: >those lines gets *interpreted* by emacs (i.e., it generate instructions >to drive a process, something very similar to python bytecode, isn't >it?) The fact that there seems to be a number of grey zone issues and dilemmas concerning GPL doesn't mean that I can't loose a court case involving GPL. It probably just means that the lawyers will charge more money from both sides... Note that the GPL says: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." The issue is whether your code and the GPL program can be considered to combine into a new program. I doubt that anyone would say that a text file with emacs editor directives is a program at all. The issue is that if I write a program that imports a number of modules, these modules are from a logical and practical point of view part of the whole program. My code won't work without them. I think you know that RMS was unhappy with the Python license, and that it was changed so that it became GPL compatible, i.e. it became possible to use code licensed under the Python license in a GPL application. With the old incompatible licence RMS seems to have considered it impossible to write GPLed python programs, since the Python interpreter and the standard library modules become part of the total program. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@initd.org Wed Oct 2 10:42:51 2002 From: fog@initd.org (Federico Di Gregorio) Date: 02 Oct 2002 11:42:51 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <3D9ABB93.6010901@lemburg.com> References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> <1033547845.1338.851.camel@momo> <3D9ABB93.6010901@lemburg.com> Message-ID: <1033551771.1096.864.camel@momo> --=-VH0lvY9hJHdUG/NhZ9uD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable a single answer and then i'll consider the argument closed. Il mer, 2002-10-02 alle 11:25, M.-A. Lemburg ha scritto: > Input and output of GPLed programs are not automatically > covered by the GPL, e.g. the GNU C compiler needs many > instructions to tell it what to do with the code, but that > doesn't make the code automatically fall under the GPL. >=20 > Please read clause 0. of the GPL and the FAQ for details. >=20 > http://www.gnu.org/licenses/gpl.html > http://www.gnu.org/licenses/gpl-faq.html the FAQ says that bytecode is data and GPL interpreters *can* execute non GPL code. why an external library simply adding functionality to the interpreter would invalid this is a mistery to me. there is confusion about bindings and the binded library (it seems that if the binded library is GPL then the bytecode should be GPL, but this is complete crap, IMO). why is an interpreter+library different from the interpreter alone? i can't answer (imo it should not.) M.-A., the problem is not as clear as you put it.. then, what will i do? simply nothing. if you have a *real* problem with psycopg licensing just write me and we'll arrange it. but don't write me on teoretical problems, we already had enough of them. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org La felicit=E0 =E8 una tazza di cioccolata calda. Sempre. -- I= o --=-VH0lvY9hJHdUG/NhZ9uD Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9mr+bvcCgrgZGjesRAhWtAKDIL/kmQ7GCKl78JhhJEUMc+lHpMACgru7z 9PTpLakvVwnK1PVF64ME1+c= =cwMP -----END PGP SIGNATURE----- --=-VH0lvY9hJHdUG/NhZ9uD-- From VKryukov@ufg.com Wed Oct 2 10:47:16 2002 From: VKryukov@ufg.com (Krjukov Victor) Date: Wed, 2 Oct 2002 13:47:16 +0400 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raises Exception Message-ID: <7CF3E427AE54FC42A26E68C5A89C186910C788@zeal.ufg.com> Greetings, db-sig, I've faced with strange mx.odbc.windows execute() behaviour. Can someone please explain me why the following code fails on 4th execute? May be I'm just missing something very simple... I'm running mx.ODBC.Windows 2.0.5 Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on win32 MS SQL server 2000 Windows 2000 =3D=3D=3D=3D> test_sql.py import mx.ODBC.Windows DB =3D mx.ODBC.Windows.Connect('db-companies') C =3D DB.cursor() sql =3D """select newsid from news where newsid between 1 and 2""" C.execute(sql) print 'ok' sql =3D """select newsid from news where newsid between ? and ?""" C.execute(sql, (1, 100)) print 'ok' sql =3D """select newsid from news where newsid in (select newsid from news where newsid between 1 and 100)""" C.execute(sql) print 'ok' sql =3D """select newsid from news where newsid in (select newsid from news where newsid between ? and ?)""" C.execute(sql, (1, 100)) print 'ok' <=3D=3D=3D=3D end of test_sql.py =3D=3D=3D=3D> result ok ok ok Traceback (most recent call last): File "", line 1, in ? File "c:/DOCUME~1/VKryukov/LOCALS~1/Temp/python-2320G8C", line 21, in ? C.execute(sql, (1, 100)) mxODBC.ProgrammingError: ('37000', 0, '[Microsoft][ODBC SQL Server Driver]Syntax error or access violation', 4469) <=3D=3D=3D=3D end of result ---- Sincerely Yours, Victor V. Kryukov, UFG phone: +7501 967 3727, ext. 4387 email: vkryukov@ufg.com From mal@lemburg.com Wed Oct 2 11:07:43 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 02 Oct 2002 12:07:43 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> <1033547845.1338.851.camel@momo> <3D9ABB93.6010901@lemburg.com> <1033551771.1096.864.camel@momo> Message-ID: <3D9AC56F.4000807@lemburg.com> Federico Di Gregorio wrote: > a single answer and then i'll consider the argument closed. > > Il mer, 2002-10-02 alle 11:25, M.-A. Lemburg ha scritto: > > >>Input and output of GPLed programs are not automatically >>covered by the GPL, e.g. the GNU C compiler needs many >>instructions to tell it what to do with the code, but that >>doesn't make the code automatically fall under the GPL. >> >>Please read clause 0. of the GPL and the FAQ for details. >> >> http://www.gnu.org/licenses/gpl.html >> http://www.gnu.org/licenses/gpl-faq.html > > > the FAQ says that bytecode is data and GPL interpreters *can* execute > non GPL code. why an external library simply adding functionality to the > interpreter would invalid this is a mistery to me. there is confusion > about bindings and the binded library (it seems that if the binded > library is GPL then the bytecode should be GPL, but this is complete > crap, IMO). why is an interpreter+library different from the interpreter > alone? i can't answer (imo it should not.) Frederico, the problem arises if someone builds an application around Python and e.g. psycopg (which I understand is GPLed) and wants to distribute that application to a different user. In this case, the application needs both Python and psycopg, so the the application forms a new work together with Python and psycopg. This is where the GPL comes in. It forces you to ship the complete work under the GPL. The situation is different if the OS the application runs on ships Python and psycopg as part of the OS. On those platforms, the already mentioned OS clause in the GPL lets you ship the application under a different license -- but only on those platforms. > M.-A., the problem is not as clear as you put it.. Oh, it is :-) The solution for an application developer is just as simple: never use GPLed code in applications which you want to deliver under non-GPL licenses. LGPL is fine, but even there, the developer should carefully read the license. > then, what will i do? simply nothing. if you have a *real* problem with > psycopg licensing just write me and we'll arrange it. but don't write me > on teoretical problems, we already had enough of them. Oh, I don't have a problem with this :-) I just wanted to clarify things a bit. It really all depends on which audience you want reach with psycopg and what kind of distribution model you have in mind (e.g. a business model, an FSF view of the world or a charity view of things). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From fog@initd.org Wed Oct 2 11:19:19 2002 From: fog@initd.org (Federico Di Gregorio) Date: 02 Oct 2002 12:19:19 +0200 Subject: [DB-SIG] Re: [Psycopg] GPL or LGPL In-Reply-To: <3D9AC56F.4000807@lemburg.com> References: <3D99CF49.9080002@devis.com> <1033506437.11757.26.camel@kernel> <3D9A1BD9.8 030005@devis.com> <1033514382.1338.324.camel@momo> <3D9AAD6C.3030004@lemburg.com> <1033547845.1338.851.camel@momo> <3D9ABB93.6010901@lemburg.com> <1033551771.1096.864.camel@momo> <3D9AC56F.4000807@lemburg.com> Message-ID: <1033553959.1346.874.camel@momo> --=-XyOQRsOwC/fVkvQ+bDNU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mer, 2002-10-02 alle 12:07, M.-A. Lemburg ha scritto: > > then, what will i do? simply nothing. if you have a *real* problem with > > psycopg licensing just write me and we'll arrange it. but don't write m= e > > on teoretical problems, we already had enough of them. >=20 > Oh, I don't have a problem with this :-) I just wanted to i know. this part was not itended for you, sorry. > clarify things a bit. It really all depends on which audience > you want reach with psycopg and what kind of distribution model > you have in mind (e.g. a business model, an FSF view of the > world or a charity view of things). --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Nessuno dice che non si possa sognare in dettaglio, essere realistici e magari realizzarlo pure, il sogno. -- --=-XyOQRsOwC/fVkvQ+bDNU Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA9msgnvcCgrgZGjesRAkSEAJ9S6WnqN81U6MXyFprmgQglXoL1sgCgtjUc IptPDpOVlQ5BG5YJlbUGwu8= =Ivvg -----END PGP SIGNATURE----- --=-XyOQRsOwC/fVkvQ+bDNU-- From mal@lemburg.com Wed Oct 2 11:18:41 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 02 Oct 2002 12:18:41 +0200 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raises Exception References: <7CF3E427AE54FC42A26E68C5A89C186910C788@zeal.ufg.com> Message-ID: <3D9AC801.7050408@lemburg.com> Krjukov Victor wrote: > Greetings, db-sig, I've faced with strange mx.odbc.windows execute() > behaviour. > > Can someone please explain me why the following code fails on 4th > execute? May be I'm just missing something very simple... > > I'm running > > mx.ODBC.Windows 2.0.5 > Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit (Intel)] on > win32 > MS SQL server 2000 > Windows 2000 > > ====> test_sql.py > import mx.ODBC.Windows > > DB = mx.ODBC.Windows.Connect('db-companies') > C = DB.cursor() > > sql = """select newsid from news where newsid between 1 and 2""" > C.execute(sql) > print 'ok' > > sql = """select newsid from news where newsid between ? and ?""" > C.execute(sql, (1, 100)) > print 'ok' > > sql = """select newsid from news where newsid in (select newsid from > news > where newsid between 1 and 100)""" > C.execute(sql) > print 'ok' > > sql = """select newsid from news where newsid in (select newsid from > news > where newsid between ? and ?)""" > C.execute(sql, (1, 100)) > print 'ok' > <==== end of test_sql.py > ====> result > ok > ok > ok > Traceback (most recent call last): > File "", line 1, in ? > File "c:/DOCUME~1/VKryukov/LOCALS~1/Temp/python-2320G8C", line 21, in > ? > C.execute(sql, (1, 100)) > mxODBC.ProgrammingError: ('37000', 0, '[Microsoft][ODBC SQL Server > Driver]Syntax error or access violation', 4469) > <==== end of result Could be a limitation of the MS SQL Server or its ODBC driver. The SQL you are using looks strange though: why would you want to nest identical SQL queries like the one above ? BTW, have you modified mxODBC in some way ? The line number indicated in the error message doesn't map to a valid line in the C code. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From VKryukov@ufg.com Wed Oct 2 11:40:46 2002 From: VKryukov@ufg.com (Krjukov Victor) Date: Wed, 2 Oct 2002 14:40:46 +0400 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raisesException Message-ID: <7CF3E427AE54FC42A26E68C5A89C186910C789@zeal.ufg.com> > Could be a limitation of the MS SQL Server or its ODBC > driver. The SQL you are using looks strange though: why > would you want to nest identical SQL queries like the > one above ? This SQL statement is strange indeed: my initial version was, of course, more complicated and includes two tables: select * from table_news where news_id in=20 (select newsid from news where date between '1979-1-1' and '1979-2-1') , where table_news has a foreign key news_id linked to primary key newsid in table news. But I have simplified it in such a way that it need only one table with only one field ;), to be sure it's a problem in execute() rather in some other place (in my initial version this exception occurs, too). The problem is that I don't face the problem when I don't use subqueries as you may find from two first execute()'s. > BTW, have you modified mxODBC in some way ? The line number > indicated in the error message doesn't map to a valid line > in the C code. No, I'm using the binary distribution version and haven't modified it (actually I don't even know how to modify .pyd files ;). I still don't understand what 'line in the C code' you are talking about; should the error message from unmodified mxODBC contained some information about line in C source in which error occurs? BTW, is it possible that this binary distribution is NOT compiled with debugging support? I've tried to use python -d switch to turn debugging as I have read in your documentation, but it doesn't lead to mxODBC.log file creation in current dir. The line numbers from previous example come from executing this script in Emacs and copy-pasting result from Emacs *Python-output* buffer; sorry for that. If I execute this in shell I'll receive: =3D=3D=3D> ok ok ok Traceback (most recent call last): File "S:\News parser\test_sql.py", line 21, in ? C.execute(sql, (1, 100)) mxODBC.ProgrammingError: ('37000', 0, '[Microsoft][ODBC SQL Server Driver]Syntax error or access violation', 4469) <=3D=3D=3D Can you please explain how parameter substitution works in execute()? Does this function do substitution itself or does it use some ODBC driver facility? In former case, it seems much like execute() bug because 3rd execute() contains statement that should occur after parameter substitution. Anyway thank you very much Marc-Andre for your useful set of utilities like mx.ODBC.Windows and mx.DateTime which I use regularly. >=20 > --=20 > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________ > _________ > eGenix.com -- Makers of the Python mx Extensions:=20 > mxDateTime,mxODBC,... > Python Consulting: =20 > http://www.egenix.com/ > Python Software: =20 > http://www.egenix.com/files/python/ >=20 >=20 From VKryukov@ufg.com Wed Oct 2 19:02:56 2002 From: VKryukov@ufg.com (Krjukov Victor) Date: Wed, 2 Oct 2002 22:02:56 +0400 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raisesException - SOLVED! Message-ID: <7CF3E427AE54FC42A26E68C5A89C186910C78D@zeal.ufg.com> Greetings again, I've find a solution to this problem. Actually this is the second time I found an answer on my question myself on the same day I post it to the newsgroup; previous one was yesterday :P. > From: M.-A. Lemburg [mailto:mal@lemburg.com]=20 > Sent: Wednesday, October 02, 2002 2:19 PM > To: Krjukov Victor > Cc: db-sig@python.org > Subject: Re: [DB-SIG] mx.ODBC.Windows - execute() parameter=20 > substitution raisesException ... > Could be a limitation of the MS SQL Server or its ODBC > driver. The SQL you are using looks strange though: why Yes, it is. Turning SQL tracing on, I've found that it is the SQLDescribeParam who returns SQL_ERROR. And in the documentation to the SQL server I've found following excerpt (see at the end of the file). The last statement explicitly states that parameters in subqueries are not supported. Uh :(. Probably I can introduce a feature request to Mr Lembert: don't rely on SQLDescribeParam and implement parameter substitution yourself (at least in mx.ODBC.Windows) :P. Sincerely Yours,=20 Victor. -----> excerpt from SQL Server Info. SQLDescribeParam To describe the parameters of any SQL statement, the Microsoft(r) SQL Server(tm) ODBC driver builds and executes a Transact-SQL SELECT statement when SQLDescribeParam is called on a prepared ODBC statement handle. The driver uses the SET FMTONLY statement when executing the query. The meta data of the result set determines the characteristics of the parameters in the prepared statement. Consider this ODBC SQL statement: INSERT INTO Shippers (ShipperID, CompanyName, Phone) VALUES (?, ?, ?) On a call to SQLDescribeParam, this ODBC SQL statement causes the driver to execute the following Transact-SQL statement: SET FMTONLY ON SELECT ShipperID, CompanyName, Phone FROM Shippers SET FMTONLY OFF SQLDescribeParam can, therefore, return any error code that SQLExecute or SQLExecDirect might return. Further, the driver does not support calling SQLDescribeParam after SQLExecDirect for any Transact-SQL UPDATE or DELETE statements containing the FROM clause; for any ODBC or Transact-SQL statement depending on a subquery containing parameters; for ODBC SQL statements containing parameter markers in both expressions of a comparison, like, or quantified predicate; or queries where one of the parameters is a parameter to a function. ... ----- From mal@lemburg.com Fri Oct 4 20:08:23 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 04 Oct 2002 21:08:23 +0200 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raisesException - SOLVED! References: <7CF3E427AE54FC42A26E68C5A89C186910C78D@zeal.ufg.com> Message-ID: <3D9DE727.5020701@lemburg.com> Krjukov Victor wrote: >>Could be a limitation of the MS SQL Server or its ODBC >>driver. The SQL you are using looks strange though: why > > Yes, it is. > > Turning SQL tracing on, I've found that it is the SQLDescribeParam who > returns SQL_ERROR. And in the documentation to the SQL server I've found > following excerpt (see at the end of the file). > > The last statement explicitly states that parameters in subqueries are > not supported. Uh :(. > > Probably I can introduce a feature request to Mr Lembert: don't rely on > SQLDescribeParam and implement parameter substitution yourself (at least > in mx.ODBC.Windows) :P. That would give away too much flexibility, esp. the implicit SQL value quoting which is implemented in the ODBC drivers (if needed by the wire protocol). Doing this in mxODBC would cause much trouble since each database has its own way of formatting value literals. In your particular case it should be easy enough to switch from ? to %s in the command string and from the comma to a percent sign between the command and the argument tuple. > Sincerely Yours, > > Victor. > > -----> excerpt from SQL Server Info. > SQLDescribeParam > To describe the parameters of any SQL statement, the Microsoft(r) SQL > Server(tm) ODBC driver builds and executes a Transact-SQL SELECT > statement when SQLDescribeParam is called on a prepared ODBC statement > handle. The driver uses the SET FMTONLY statement when executing the > query. The meta data of the result set determines the characteristics of > the parameters in the prepared statement. > > Consider this ODBC SQL statement: > > INSERT INTO Shippers (ShipperID, CompanyName, Phone) VALUES (?, ?, ?) > > On a call to SQLDescribeParam, this ODBC SQL statement causes the driver > to execute the following Transact-SQL statement: > > SET FMTONLY ON SELECT ShipperID, CompanyName, Phone FROM Shippers SET > FMTONLY OFF > > SQLDescribeParam can, therefore, return any error code that SQLExecute > or SQLExecDirect might return. > > Further, the driver does not support calling SQLDescribeParam after > SQLExecDirect for any Transact-SQL UPDATE or DELETE statements > containing the FROM clause; for any ODBC or Transact-SQL statement > depending on a subquery containing parameters; for ODBC SQL statements > containing parameter markers in both expressions of a comparison, like, > or quantified predicate; or queries where one of the parameters is a > parameter to a function. > ... > ----- -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Fri Oct 4 20:10:50 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 04 Oct 2002 21:10:50 +0200 Subject: [DB-SIG] mx.ODBC.Windows - execute() parameter substitution raisesException References: <7CF3E427AE54FC42A26E68C5A89C186910C789@zeal.ufg.com> Message-ID: <3D9DE7BA.8040407@lemburg.com> Krjukov Victor wrote: >>BTW, have you modified mxODBC in some way ? The line number >>indicated in the error message doesn't map to a valid line >>in the C code. > > > No, I'm using the binary distribution version and haven't modified it > (actually I don't even know how to modify .pyd files ;). Strange. Must be the MSVC compiler messing up the line numbers. > I still don't understand what 'line in the C code' you are talking > about; should the error message from unmodified mxODBC contained some > information about line in C source in which error occurs? Yes: the last entry in the error tuple is the line number in the C code which produced the exception. Makes support a lot easier. > BTW, is it > possible that this binary distribution is NOT compiled with debugging > support? I've tried to use python -d switch to turn debugging as I have > read in your documentation, but it doesn't lead to mxODBC.log file > creation in current dir. That's true: the release versions don't ship with debugging code. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From dyoo@hkn.eecs.berkeley.edu Mon Oct 7 16:45:08 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Mon, 7 Oct 2002 08:45:08 -0700 (PDT) Subject: [DB-SIG] Re: [meta-sig] select statement for python-mysql In-Reply-To: <200210070957.10883.mclay@nist.gov> Message-ID: > > im facing a problem with the syntax in python-mysql. this is my code: > > > > > > The syntax for the string substitution needs to have a '%' instead of a ',' > > c.execute("""select vid from verses where > book,chapter,number=%s,%s,%s""" %(bk,chap,i)) [redirected to db-sig] The syntax of that select SQL statement itself looks funny to me; are you sure you don't mean this instead? select vid from verses where book = %s and chapter = %s and number = %s Good luck! From dyoo@hkn.eecs.berkeley.edu Mon Oct 7 16:52:37 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Mon, 7 Oct 2002 08:52:37 -0700 (PDT) Subject: [DB-SIG] Re: [meta-sig] select statement for python-mysql In-Reply-To: <200210070957.10883.mclay@nist.gov> Message-ID: >> c.execute("""select vid from verses where >> book,chapter,number=%s,%s,%s""", (bk,chap,i)) > > The syntax for the string substitution needs to have a '%' instead of a ',' Roslyn was right to use a comma: the execute() method of a database cursor can take in an optional tuple, in which case we're using the safer prepared statement syntax. Roslyn probably does not want to use string formatting due to some issues that SQL deals with. In particular, we neeed to use prepared statement syntax in cases where we're inserting columns with nulls, for example: ### c.execute("insert into book (title, author, isbn) value (%s, %s, %s)", ("sicp", "abelson & sussmann", None)) ### Trying to do the equivalent with a string formatting operation: ### c.execute("insert into book (title, author, isbn) value (%s, %s, %s)" % ("sicp", "abelson & sussmann", None) ) ### won't work. Good luck! From plusk@radford.edu Mon Oct 7 22:00:39 2002 From: plusk@radford.edu (plusk@radford.edu) Date: Mon, 7 Oct 2002 17:00:39 -0400 Subject: [DB-SIG] Compiling DCOracle2 on HPUX Message-ID: <1034024439.3da1f5f72bf46@www.portal.radford.edu> I've been advocating the use of python here (Radford University). I've demonstrated some programs that my bosses found interesting, using DCOracle2 and mx.DateTime on Win2K. My bosses worry about the costs of deploy program on all our users' machine and would prefer that I get things to work on our HPUX box. I have a sympathetic admin helping me, and he was able to install mx.DateTime. the DCOracle2 package did not install because it could not find a lib it needed. sys.platform is hp-ux11 oracle is 64 bit 9.2.0.1.0 # make (cd src; \ ./testora python) -n Checking ORACLE_HOME... passed. -n Checking for Oracle version... failed. /u01/app/oracle/product/9.2.0.1/lib/libclntsh.so not readable; unable to determine your oracle version. *** Error exit code 2 Stop. Any help would be appreciated. Paul ------------------------------------------------------ This mail sent through https://www.portal.radford.edu From matt@zope.com Mon Oct 7 22:06:06 2002 From: matt@zope.com (Matthew T. Kromer) Date: Mon, 07 Oct 2002 17:06:06 -0400 Subject: [DB-SIG] Compiling DCOracle2 on HPUX References: <1034024439.3da1f5f72bf46@www.portal.radford.edu> Message-ID: <3DA1F73E.5010503@zope.com> plusk@radford.edu wrote: >I've been advocating the use of python here (Radford University). >I've demonstrated some programs that my bosses found interesting, using >DCOracle2 and mx.DateTime on Win2K. My bosses worry about the costs of deploy >program on all our users' machine and would prefer that I get things to work >on our HPUX box. I have a sympathetic admin helping me, and he was able to >install mx.DateTime. >the DCOracle2 package did not install because it could not find a >lib it needed. > >sys.platform is hp-ux11 > >oracle is 64 bit 9.2.0.1.0 > ># make > (cd src; \ > ./testora python) >-n Checking ORACLE_HOME... >passed. >-n Checking for Oracle version... >failed. >/u01/app/oracle/product/9.2.0.1/lib/libclntsh.so not readable; unable to >determine your oracle version. >*** Error exit code 2 > >Stop. > >Any help would be appreciated. > >Paul > I dont konw much about hp-ux -- What the test program is trying to do is do a "nm" on that shared object looking for various symbols. Can you verify that u01/app/oracle/product/9.2.0.1/lib/libclntsh.so exists, and is readable? If it doesn't exist, look for libclntsh* type names in that directory. You may have to adjust names somewhat in the scripts to get them to recognize HPUX shared libraries. All it is trying to do is create a makefile with the right defines set up. You can try running python setup.py build instead, as distutils might have more of a clue about hpux than I do. You may have to tweak the CFLAGS and LFLAGS variables in setup as well, since they're set up for gcc. -- Matt Kromer Zope Corporation http://www.zope.com/ From msanchez@grupoburke.com Tue Oct 8 07:56:19 2002 From: msanchez@grupoburke.com (Marcos =?ISO-8859-1?Q?S=E1nchez?= Provencio) Date: 08 Oct 2002 08:56:19 +0200 Subject: [DB-SIG] Compiling DCOracle2 on HPUX In-Reply-To: <1034024439.3da1f5f72bf46@www.portal.radford.edu> References: <1034024439.3da1f5f72bf46@www.portal.radford.edu> Message-ID: <1034060179.1464.6.camel@renata.macondo.pri> There is a script that makes libclntsh.so; you may have to run it to be able to link programs against your Oracle installation. The script is supposed to be harmless, but you might need to recompile other programs that use this library. The second issue is to simply verify permissions. I hope it helps; I managed to compile DCOracle2 in Solaris (SunOS 4.2 or something). The server was oracle 7, but everything worked fine when the 8i client was installed. The funny thing is that the v8 client needs to have some listener started, which v7 programs don't. You can tell by my language that I am an Oracle expert :-) El lun, 07-10-2002 a las 23:00, plusk@radford.edu escribi=F3: > I've been advocating the use of python here (Radford University). > I've demonstrated some programs that my bosses found interesting, using > DCOracle2 and mx.DateTime on Win2K. My bosses worry about the costs of de= ploy > program on all our users' machine and would prefer that I get things to w= ork > on our HPUX box. I have a sympathetic admin helping me, and he was able t= o=20 > install mx.DateTime.=20 > the DCOracle2 package did not install because it could not find a=20 > lib it needed.=20 >=20 > sys.platform is hp-ux11 >=20 > oracle is 64 bit 9.2.0.1.0 >=20 > # make > (cd src; \ > ./testora python) > -n Checking ORACLE_HOME... > passed. > -n Checking for Oracle version... > failed. > /u01/app/oracle/product/9.2.0.1/lib/libclntsh.so not readable; unable to > determine your oracle version. > *** Error exit code 2 >=20 > Stop. >=20 > Any help would be appreciated. >=20 > Paul >=20 >=20 > ------------------------------------------------------ > This mail sent through https://www.portal.radford.edu >=20 > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From harri.pasanen@trema.com Tue Oct 8 08:25:09 2002 From: harri.pasanen@trema.com (Harri Pasanen) Date: Tue, 8 Oct 2002 09:25:09 +0200 Subject: [DB-SIG] Compiling DCOracle2 on HPUX In-Reply-To: <3DA1F73E.5010503@zope.com> References: <1034024439.3da1f5f72bf46@www.portal.radford.edu> <3DA1F73E.5010503@zope.com> Message-ID: <200210080925.09793.harri.pasanen@trema.com> On Monday 07 October 2002 23:06, Matthew T. Kromer wrote: > plusk@radford.edu wrote: > >I've been advocating the use of python here (Radford University). > >I've demonstrated some programs that my bosses found interesting, usin= g > >DCOracle2 and mx.DateTime on Win2K. My bosses worry about the costs of > > deploy program on all our users' machine and would prefer that I get > > things to work on our HPUX box. I have a sympathetic admin helping me= , > > and he was able to install mx.DateTime. > >the DCOracle2 package did not install because it could not find a > >lib it needed. > > > >sys.platform is hp-ux11 > > > >oracle is 64 bit 9.2.0.1.0 > > > ># make > > (cd src; \ > > ./testora python) > >-n Checking ORACLE_HOME... > >passed. > >-n Checking for Oracle version... > >failed. > >/u01/app/oracle/product/9.2.0.1/lib/libclntsh.so not readable; unable = to > >determine your oracle version. > >*** Error exit code 2 > > > >Stop. > > > >Any help would be appreciated. > > > >Paul > > I dont konw much about hp-ux -- What the test program is trying to do i= s > do a "nm" on that shared object looking for various symbols. Can you > verify that > > u01/app/oracle/product/9.2.0.1/lib/libclntsh.so > > > exists, and is readable? If it doesn't exist, look for libclntsh* type > names in that directory. You may have to adjust names somewhat in the > scripts to get them to recognize HPUX shared libraries. > On HP-UX the shared library extension is .sl, so the lib is probably call= ed=20 /u01/app/oracle/product/9.2.0.1/lib/libclntsh.sl -Harri > All it is trying to do is create a makefile with the right defines set > up. You can try running > > python setup.py build > > instead, as distutils might have more of a clue about hpux than I do. > You may have to tweak the CFLAGS and LFLAGS variables in setup as well= , > since they're set up for gcc. From jekabs.andrusaitis@tietoenator.com Tue Oct 8 09:10:16 2002 From: jekabs.andrusaitis@tietoenator.com (Jekabs Andrushaitis) Date: Tue, 8 Oct 2002 10:10:16 +0200 Subject: [DB-SIG] MySQL Python module bugs or what? In-Reply-To: Message-ID: <000701c26ea2$23773f10$262a949f@konts.lv> SQL code: CREATE TABLE testtable(testfield longint); INSERT INTO testtable(testfield) VALUES(1); Python code: ... # this works dbc.execute("SELECT testfield FROM testtable WHERE testfield<1") print dbc.fetchall() # this fails by saying that integer is required for parameter!!! dbc.execute("SELECT testfield FROM testtable WHERE testfield<%d",(1,)) print dbc.fetchall() # this also fails by saying that integer is required for parameter!!! dbc.execute("SELECT testfield FROM testtable WHERE testfield<%(testfield)d",{"testfield":1}) print dbc.fetchall() # and naturally this produces same dbc.execute("SELECT testfield FROM testtable WHERE testfield<%ld",(long(1),)) print dbc.fetchall() # white this works... dbc.execute("SELECT testfield FROM testtable WHERE testfield<%s",(1,)) print dbc.fetchall() Am I missing something serious, or this is a bug in MySQLdb module? Was using latest stable release from sourceforge.net. Also, I never managed to insert a longblob value whose side exceeded 1Mb into table. Not that I care about this much now, I did it couple weeks earlier when I had to migrate bug/request/feature request tracking data from our own Python/PostgreSQL/mod_python based solution to Bugzilla (sad, but I liked our own tracking application MUCH better than Bugzilla and the PHP). Jekabs Andrushaitis Senior system analyst TietoEnator Financial Solutions 41 Lacplesa Str. Riga, LV-1011, Latvia Tel: +371 7286660 Fax: +371 7243000 E-mail: jekabs.andrusaitis@tietoenator.com From gerhard.haering@opus-gmbh.net Tue Oct 8 10:36:56 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 8 Oct 2002 11:36:56 +0200 Subject: [DB-SIG] Compiling DCOracle2 on HPUX In-Reply-To: <1034024439.3da1f5f72bf46@www.portal.radford.edu> References: <1034024439.3da1f5f72bf46@www.portal.radford.edu> Message-ID: <20021008093656.GA1300@HAERING> * plusk@radford.edu [2002-10-07 17:00 -0400]: > I've been advocating the use of python here (Radford University). > I've demonstrated some programs that my bosses found interesting, using > DCOracle2 and mx.DateTime on Win2K. My bosses worry about the costs of deploy > program on all our users' machine and would prefer that I get things to work > on our HPUX box. I have a sympathetic admin helping me, and he was able to > install mx.DateTime. > the DCOracle2 package did not install because it could not find a > lib it needed. Looks like you're having a different problem than I had recently with DCOracle2 on HP/Unix. As a consequence, I wrote a quick HOWTO for our internal Wiki. Here's a translation - perhaps it will help somebody: --- This is the PyhtonOnHpUnix HOWTO. It may be possible to get it running more easily (with the Python binary from http://hpux.cs.utah.edu/hppd/hpux/Languages/python-2.2.1/) These are only the facts, for background and details only RTFM will help. 1 Development Environment * Have the sysadmin install gcc 3.1 from the above URL * Put mxExtensions, cx_Oracle und DCOracle2 sources on the box * Put Python 2.2.1 sources on the box 2 Compile Python * untar Python 2.2.1 sources * Call ./configure --prefix=~/ * Manually edit the Makefile (that's the ugly step), such that Python links against a certain library called "cl". Search the variable which determines which libraries Python links against. I've simply searched for "pthread", then inserted "cl" there. * make * make test (to look if everything works ok) * make install * Put the Python you compiled yourself in the PATH 3 Compile mxExtensions * untar mxExtensions * python setup.py build * python setup.py install 4 Compile DCOracle2 * untar DCOracle2 * make sure that ORACLE_HOME is set correctly * change setup.py such that LFLAGS is set to an empty list, otherwise the linker of HP-Unix will complain * python setup.py build * python setup.py install 5 Compile cx_Oracle * I don't currently use this database interface, but wanted to get an alternative to DCOracle2 * untar cx_Oracle * make sure ORACLE_HOME is set correctly * python setup.py build * python setup.py install -- Gerhard Häring OPUS GmbH München Tel.: +49 89 - 889 49 7 - 32 http://www.opus-gmbh.net/ From chris@cogdon.org Tue Oct 8 16:43:14 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 8 Oct 2002 08:43:14 -0700 Subject: [DB-SIG] MySQL Python module bugs or what? In-Reply-To: <000701c26ea2$23773f10$262a949f@konts.lv> Message-ID: On Tuesday, Oct 8, 2002, at 01:10 US/Pacific, Jekabs Andrushaitis wrote: > SQL code: > CREATE TABLE testtable(testfield longint); > INSERT INTO testtable(testfield) VALUES(1); > > Python code: > ... > # this works > dbc.execute("SELECT testfield FROM testtable WHERE testfield<1") > print dbc.fetchall() > > # this fails by saying that integer is required for parameter!!! > dbc.execute("SELECT testfield FROM testtable WHERE testfield<%d",(1,)) > print dbc.fetchall() > > # this also fails by saying that integer is required for parameter!!! > dbc.execute("SELECT testfield FROM testtable WHERE > testfield<%(testfield)d",{"testfield":1}) > print dbc.fetchall() > > # and naturally this produces same > dbc.execute("SELECT testfield FROM testtable WHERE > testfield<%ld",(long(1),)) > print dbc.fetchall() > > # white this works... > dbc.execute("SELECT testfield FROM testtable WHERE testfield<%s",(1,)) > print dbc.fetchall() > > Am I missing something serious, or this is a bug in MySQLdb module? Was > using latest stable release > from sourceforge.net. Also, I never managed to insert a longblob value > whose > side exceeded 1Mb into > table. > > Not that I care about this much now, I did it couple weeks earlier > when I > had to migrate bug/request/feature request > tracking data from our own Python/PostgreSQL/mod_python based solution > to > Bugzilla (sad, but I liked our own > tracking application MUCH better than Bugzilla and the PHP). You have to use %s, even if you're dealing with integers. The 'quoting' code inside the DBI module turns all the parameters into strings before passing it to a python % operator. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From jekabs.andrusaitis@tietoenator.com Tue Oct 8 16:48:40 2002 From: jekabs.andrusaitis@tietoenator.com (Jekabs Andrushaitis) Date: Tue, 8 Oct 2002 17:48:40 +0200 Subject: [DB-SIG] MySQL Python module bugs or what? In-Reply-To: Message-ID: <000001c26ee2$2d268a80$262a949f@konts.lv> > You have to use %s, even if you're dealing with integers. The > 'quoting' > code inside the DBI module turns all the parameters into > strings before > passing it to a python % operator. Is it how that is SUPPOSED to be, or just a case about MySQLdb? psycopg module in pyformat binding mode happily accepts most format strings like regular % operator does. I havent looked into DBAPI about this, but it seems to me that binding methods should be consistent between different modules. We already have 4 different types of binding (if not more), but speaking of pyformat - isnt it supposed to accept anything Python % would accept? Any comments on largeblob datatype under MySQLdb? It just fails with data >1Mb!!! As I noted in my first mail, this is not a "party sopper" for me, just something I noticed and had to work around (I used %s for all bind variables under MySQL). Jekabs Andrushaitis Senior system analyst TietoEnator Financial Solutions 41 Lacplesa Str. Riga, LV-1011, Latvia Tel: +371 7286660 Fax: +371 7243000 E-mail: jekabs.andrusaitis@tietoenator.com From chris@cogdon.org Tue Oct 8 17:13:32 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 8 Oct 2002 09:13:32 -0700 Subject: [DB-SIG] MySQL Python module bugs or what? In-Reply-To: <000001c26ee2$2d268a80$262a949f@konts.lv> Message-ID: On Tuesday, Oct 8, 2002, at 08:48 US/Pacific, Jekabs Andrushaitis wrote: >> You have to use %s, even if you're dealing with integers. The >> 'quoting' >> code inside the DBI module turns all the parameters into >> strings before >> passing it to a python % operator. > > Is it how that is SUPPOSED to be, or just a case about MySQLdb? > psycopg module in pyformat binding mode happily accepts most format > strings like regular % operator does. > > I havent looked into DBAPI about this, but it seems to me that > binding methods should be consistent between different modules. You can probably use %s for any DBI module. The documentation predicates using %s It's possible that psycopg just happens to pass through integers as integers, which both %d and %s will handle, but other DBIs always pass through as strings. So, yes, I believe it will work if you use %s ALL the time. > We already have 4 different types of binding (if not more), but > speaking > of pyformat - isnt it supposed to accept anything Python % would > accept? No. 'pyformat' means specifically using pythons %(variable)s dictionary binding, rather than the more C-like %s array binding. It was not intended to reference the variable types. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From neel@mediapulse.com Tue Oct 8 21:32:05 2002 From: neel@mediapulse.com (Michael C. Neel) Date: Tue, 8 Oct 2002 16:32:05 -0400 Subject: [DB-SIG] ping method for connection objects Message-ID: Just a request for the spec, is that a ping method be added to the connection object to test if the db handle is still valid, not unlike perl's DBI interface. Ideally a reconnect method would be handy as well. Otherwise, I find the spec very complete! mike -- Michael C. Neel There are only 10 types of people in the world; those who understand binary and those who don't. From mal@lemburg.com Tue Oct 8 21:45:33 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 08 Oct 2002 22:45:33 +0200 Subject: [DB-SIG] ping method for connection objects References: Message-ID: <3DA343ED.6010006@lemburg.com> Michael C. Neel wrote: > Just a request for the spec, is that a ping method be added to the > connection object to test if the db handle is still valid, not unlike > perl's DBI interface. Ideally a reconnect method would be handy as > well. I'm not sure whether such a feature is available on a broad enough basis, e.g. ODBC only recently added such a feature to the spec and it's not available in all drivers. Maybe we just need a portable way to test the connection, e.g. a dummy SQL statement ? try: connection.cursor().execute('select x from nonexistingtable') except OperationalError: # reconnect pass except ProgrammingError: # alive pass > Otherwise, I find the spec very complete! Same here :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From chris@cogdon.org Tue Oct 8 21:57:40 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 8 Oct 2002 13:57:40 -0700 Subject: [DB-SIG] ping method for connection objects In-Reply-To: <3DA343ED.6010006@lemburg.com> Message-ID: <95259E72-DB00-11D6-99BA-000393A6D442@cogdon.org> On Tuesday, Oct 8, 2002, at 13:45 US/Pacific, M.-A. Lemburg wrote: > Michael C. Neel wrote: >> Just a request for the spec, is that a ping method be added to the >> connection object to test if the db handle is still valid, not unlike >> perl's DBI interface. Ideally a reconnect method would be handy as >> well. > > I'm not sure whether such a feature is available on a broad > enough basis, e.g. ODBC only recently added such a feature > to the spec and it's not available in all drivers. > > Maybe we just need a portable way to test the connection, > e.g. a dummy SQL statement ? > > try: > connection.cursor().execute('select x from nonexistingtable') > except OperationalError: > # reconnect > pass > except ProgrammingError: > # alive > pass > >> Otherwise, I find the spec very complete! > > Same here :-) Well, isn't the the entire purpose of the DBI? Ie, should we not create a method that either uses the database's particular 'are you there', method, or emulates it using something like the above construct. ?? For example: in the specification: connection.ping() will test the database connection and return an exception if the connection is broken in an implementation who's backend database has a ping method: def ping ( self ): if not self._db.ping () raise OperationalError in an implementation who's backend database does not have a ping method: def ping ( self ): try: connection.cursor().execute('select x from nonexistingtable') except OperationalError: # reconnect pass except ProgrammingError: # alive pass Or something like this. ie, the whole idea of a DBABI is to remove the reliance on the particular implementation for the DB. If a particular method starts to become widely available over a set of databases, this method should be added to the next rev of the API, and API writers instructed to call the method, or emulate it. To help the API writers, it would be easy enough to write a 'base class' that the API can inherit from to supply common emulations for these special methods, so all the API writer needs to do is replace the method if a more-efficient method is available for that particular DB, or if the particular emulation doesn't work for that DB. This is the same argument for ensuring that python operators work the same way over all implementations, rather than saying "the XYZ operator's behavior is dependant on the underlying C module". -- ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' FC1.3: FFH3cmA+>++C++D++H++M++P++R++T+++WZ++Sm++ ((,.-' ((,/ fL RLCT acl+++d++e+f+++h++i++++jp-sm++ From neel@mediapulse.com Tue Oct 8 22:20:01 2002 From: neel@mediapulse.com (Michael C. Neel) Date: Tue, 8 Oct 2002 17:20:01 -0400 Subject: [DB-SIG] ping method for connection objects Message-ID: I think the driver could handle what you outline, if the db did not have a real ping method. So a ping could be a "select 1" if no true ping was available. I even think the perl DBI docs state they work similar. The reconnect would just save a bit of work, and re-use the same object that might have been passed around a bit. =20 To be honest, I've only ever needed this in a webserver setup; and then I just sub class the db myself and add these in. I guess if I was really into it, I'd setup the db object to reconnect if needed by itself, hehe. Mike -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com]=20 Sent: Tuesday, October 08, 2002 4:46 PM To: Michael C. Neel Cc: db-sig@python.org Subject: Re: [DB-SIG] ping method for connection objects Michael C. Neel wrote: > Just a request for the spec, is that a ping method be added to the > connection object to test if the db handle is still valid, not unlike > perl's DBI interface. Ideally a reconnect method would be handy as > well. I'm not sure whether such a feature is available on a broad enough basis, e.g. ODBC only recently added such a feature to the spec and it's not available in all drivers. Maybe we just need a portable way to test the connection, e.g. a dummy SQL statement ? try: connection.cursor().execute('select x from nonexistingtable') except OperationalError: # reconnect pass except ProgrammingError: # alive pass > Otherwise, I find the spec very complete! Same here :-) --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Wed Oct 9 09:33:18 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 09 Oct 2002 10:33:18 +0200 Subject: [DB-SIG] ping method for connection objects References: Message-ID: <3DA3E9CE.7090202@lemburg.com> Michael C. Neel wrote: > I think the driver could handle what you outline, if the db did not have > a real ping method. So a ping could be a "select 1" if no true ping was > available. I even think the perl DBI docs state they work similar. "select 1" is not portable. It is also not clear that the driver will actually check the network connection that way. > The reconnect would just save a bit of work, and re-use the same object > that might have been passed around a bit. > > To be honest, I've only ever needed this in a webserver setup; and then > I just sub class the db myself and add these in. I guess if I was > really into it, I'd setup the db object to reconnect if needed by > itself, hehe. Same here. The typical setup to implement reconnects and keep-alives is a database connection pooling mechanism which is usually built on top of the low-level drivers as abstraction layer. If you'd like a .ping() method on connections, I could add it as standard extension to the spec, but I doubt that it will get implemented by many interface authors. A .reconnect() method would not be in line with the spec (once you close a connection it becomes useless). But that's easy to handle by a connect wrapper function, if you need it. Please remember that the DB API focuses on the low-level aspects of talking to databases, not the more involved issues like connection pooling, automatic reconnect, schema analysis or even object-relational mappings. That's left for layers on top of the DB API to implement. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jno@glasnet.ru Wed Oct 9 11:00:10 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Wed, 9 Oct 2002 14:00:10 +0400 Subject: [DB-SIG] Re: [meta-sig] select statement for python-mysql In-Reply-To: References: <200210070957.10883.mclay@nist.gov> Message-ID: <20021009100010.GE14540@glas.net> On Mon, Oct 07, 2002 at 08:45:08AM -0700, Danny Yoo wrote: > > > > > im facing a problem with the syntax in python-mysql. this is my code: > > > > > > > > > > The syntax for the string substitution needs to have a '%' instead of a ',' > > > > c.execute("""select vid from verses where > > book,chapter,number=%s,%s,%s""" %(bk,chap,i)) > > [redirected to db-sig] > > The syntax of that select SQL statement itself looks funny to me; are you > sure you don't mean this instead? > > select vid from verses > where book = %s > and chapter = %s > and number = %s ÈÍ-ÈÍ... × ïÒÁËÌÅ ÔÁËÁÑ ÆÅÎÑ ÒÁÂÏÔÁÅÔ: ROAMING@ROAMING> select * from user_list where (User_ID,Realm_ID,Log_ID) in ((5,16,65)) Prefix_ID=NULL User_ID=5 Realm_ID=16 Log_ID=65 Status='W' Sim_Sessions=NULL Setup=4 # SELECT executed in 0.01 seconds # 1 record fetched (103.64 records per second) -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From jno@glasnet.ru Wed Oct 9 11:01:07 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Wed, 9 Oct 2002 14:01:07 +0400 Subject: [DB-SIG] Re: [meta-sig] select statement for python-mysql In-Reply-To: References: <200210070957.10883.mclay@nist.gov> Message-ID: <20021009100107.GF14540@glas.net> On Mon, Oct 07, 2002 at 08:45:08AM -0700, Danny Yoo wrote: > > > > > im facing a problem with the syntax in python-mysql. this is my code: > > > > > > > > > > The syntax for the string substitution needs to have a '%' instead of a ',' > > > > c.execute("""select vid from verses where > > book,chapter,number=%s,%s,%s""" %(bk,chap,i)) > > [redirected to db-sig] > > The syntax of that select SQL statement itself looks funny to me; are you > sure you don't mean this instead? > > select vid from verses > where book = %s > and chapter = %s > and number = %s oops, sorry - previous reply was in russian ;-) Oracle allows this way of coding: ROAMING@ROAMING> select * from user_list where (User_ID,Realm_ID,Log_ID) in ((5,16,65)) Prefix_ID=NULL User_ID=5 Realm_ID=16 Log_ID=65 Status='W' Sim_Sessions=NULL Setup=4 # SELECT executed in 0.01 seconds # 1 record fetched (103.64 records per second) -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From neel@mediapulse.com Wed Oct 9 19:16:04 2002 From: neel@mediapulse.com (Michael C. Neel) Date: Wed, 9 Oct 2002 14:16:04 -0400 Subject: [DB-SIG] ping method for connection objects Message-ID: Inline... >"select 1" is not portable. It is also not clear that the driver >will actually check the network connection that way. Would it have to be portable? A driver would know if it's database had a true connection test method, or know if select 1 would work correctly or not. The gem of a .ping method is the user doesn't have to worry about how to test a connection, or about changing that method should the database change. >If you'd like a .ping() method on connections, I could add it >as standard extension to the spec, but I doubt that it will get >implemented by many interface authors. >A .reconnect() method would not be in line with the spec (once >you close a connection it becomes useless). But that's easy to >handle by a connect wrapper function, if you need it. The main reason to have a reconnect method is to allow the current object to be reused. You'll have to forgive me on the following example, as I'm still somewhat new to the deeper parts of python, so this may not work like I outline. Take a python script and connect to the database, then pass the db object to two other child objects. Child A notices that the db handle has gone stale, and reconnects the normal way, with another call to create a new object. Child B never knows about this, because that new object would be in A's space. In C I could share a pointer to get around this, C++ pass by reference, and there may be some options in python as well. plus, it would simplify handle testing code across all drivers down to: if !db.ping(): db.reconnect()=20 Reconnecting would not need to know hostname, username, password, etc; it would just use whatever was set in the connect statement. >Please remember that the DB API focuses on the low-level >aspects of talking to databases, not the more involved issues >like connection pooling, automatic reconnect, schema analysis >or even object-relational mappings. That's left for layers on top >of the DB API to implement. I would even go so far as to say some of these things should be looked at for a 3.0 spec. Pooling is something that has to be done quite often, and having it driver level makes sense. A few options to the connect statement could set this up for the user. Automatic reconnect could also be some with connect options. Is that traditional db driver-like? No, but I don't think that should have any bearing on the matter. We (programmers) should be looking to new languages to simplify our life, not recreate old interfaces in new syntax. Laziness, Impatience, Hubris - Larry Wall and perl isn't all bad! Mike -- Michael C. Neel There are only 10 types of people in the world; those who understand binary and those who don't. From johannes@erdfelt.com Thu Oct 10 19:52:13 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 10 Oct 2002 14:52:13 -0400 Subject: [DB-SIG] Portable method of determining which column wasn't unique? Message-ID: <20021010145213.H3834@sventech.com> I have a table which has multiple unique columns on it. My problem is that when I insert a row which violates the unique restraint, I can't figure out which column caused the problem. I'm using MySQLdb (0.9.1 on Python 2.2.1). The example is something like this: create table foo ( a int not null, b int not null, unique (a), unique (b) ) >>> c.execute("insert into foo (a, b) values (1, 2)") 1L >>> c.execute("insert into foo (a, b) values (3, 4)") 1L >>> c.execute("insert into foo (a, b) values (1, 4)") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 61, in execute r = self._query(query) File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 169, in _query rowcount = self._BaseCursor__do_query(q) File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 112, in __do_query db.query(q) _mysql_exceptions.IntegrityError: (1062, "Duplicate entry '4' for key 1") Now, I'd like to figure out which columns were the problem, so I can report back to the user what they need to fix. I'd like to do this in a portable way, but I'll settle for something specific to MySQLdb if need be. Ignoring the fact that the exception and error code are specific to MySQLdb (is there any work on standardizing any of these?), I can't retrieve much information from the exception other than parsing the string. The next issue is that I don't know what key "1" is programmatically. I've done some hacking and I've figured out that I can combine the data from cursor._result._describe() (cursor.description) and cursor._result._field_flags() (hacked the source to make it cursor.field_flags) to determine which columns have a unique constraint or are a primary key. I could then do a query on those columns with the values I tried to change to see if any others exist. I'd need to use locks to avoid races which would make this slow. Is there a better way for MySQLdb? For DB API? Or am I just expecting too much? :) JE From ramrom@earthling.net Thu Oct 10 20:48:24 2002 From: ramrom@earthling.net (Bob Gailer) Date: Thu, 10 Oct 2002 13:48:24 -0600 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <20021010145213.H3834@sventech.com> Message-ID: <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> --=======656C2237======= Content-Type: text/plain; x-avg-checked=avg-ok-5A831DF4; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 02:52 PM 10/10/2002 -0400, you wrote: I have a table which has multiple unique columns on it. My problem is that when I insert a row which violates the unique restraint, I can't figure out which column caused the problem. Just a stab in the dark - but I am suspicious of a data model that requires unique values in two (or more) columns. Can you verify that this is really needed?. Also are the users of the system providing these values directly? You could : select * from table where unique-column1 = proposed-new-value1 select * from table where unique-column2 = proposed-new-value2 If you get a row in either case then you know the corresponding new value's already in use, Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --=======656C2237=======-- From johannes@erdfelt.com Thu Oct 10 20:57:32 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 10 Oct 2002 15:57:32 -0400 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net>; from ramrom@earthling.net on Thu, Oct 10, 2002 at 01:48:24PM -0600 References: <20021010145213.H3834@sventech.com> <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> Message-ID: <20021010155732.A4680@sventech.com> On Thu, Oct 10, 2002, Bob Gailer wrote: > At 02:52 PM 10/10/2002 -0400, you wrote: > > > I have a table which has multiple unique columns on it. My problem is that > > when I insert a row which violates the unique restraint, I can't figure out > > which column caused the problem. > > Just a stab in the dark - but I am suspicious of a data model that requires > unique values in two (or more) columns. Can you verify that this is really > needed?. Yes. The two values are a username and an email address. username is unique for obvious reasons and the email address is unique because it provides an alternate means of logging in. > Also are the users of the system providing these values directly? Yes. The user chooses their own username and their email addres is their own. > You could : > select * from table where unique-column1 = proposed-new-value1 > select * from table where unique-column2 = proposed-new-value2 > If you get a row in either case then you know the corresponding new value's > already in use, That has the same races as the possible solution I came up with that I described at the end of my original email. Another insert came come in between the select and the insert. I was hoping to make this efficient and not require explicitly locking the table since the table receives queries often. I was also hoping to keep it portable across multiple databases (hence the relevance to db-sig) JE From dustin+pydbsig@spy.net Thu Oct 10 21:08:11 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 10 Oct 2002 13:08:11 -0700 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <20021010155732.A4680@sventech.com> Message-ID: Around 15:57 on Oct 10, 2002, Johannes Erdfelt said: The correct way to do it is to have a unique index that spans those two columns. If your insert fails, the name's taken. # On Thu, Oct 10, 2002, Bob Gailer wrote: # > At 02:52 PM 10/10/2002 -0400, you wrote: # > # > > I have a table which has multiple unique columns on it. My problem is that # > > when I insert a row which violates the unique restraint, I can't figure out # > > which column caused the problem. # > # > Just a stab in the dark - but I am suspicious of a data model that requires # > unique values in two (or more) columns. Can you verify that this is really # > needed?. # # Yes. The two values are a username and an email address. # # username is unique for obvious reasons and the email address is unique # because it provides an alternate means of logging in. # # > Also are the users of the system providing these values directly? # # Yes. The user chooses their own username and their email addres is their # own. # # > You could : # > select * from table where unique-column1 = proposed-new-value1 # > select * from table where unique-column2 = proposed-new-value2 # > If you get a row in either case then you know the corresponding new value's # > already in use, # # That has the same races as the possible solution I came up with that I # described at the end of my original email. # # Another insert came come in between the select and the insert. # # I was hoping to make this efficient and not require explicitly locking # the table since the table receives queries often. # # I was also hoping to keep it portable across multiple databases (hence # the relevance to db-sig) # # JE # # # _______________________________________________ # DB-SIG maillist - DB-SIG@python.org # http://mail.python.org/mailman/listinfo/db-sig # # -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From TKeating@origin.ea.com Thu Oct 10 21:08:53 2002 From: TKeating@origin.ea.com (Keating, Tim) Date: Thu, 10 Oct 2002 15:08:53 -0500 Subject: [DB-SIG] Portable method of determining which column wasn't u nique? Message-ID: <9B8090A2F0EBDB4ABD59B08E81C1A6842F6650@osi-postal.osi.ad.ea.com> A better way to deal with this might be to break up your tables along functional lines. Right now it sounds like you are trying to store login credentials and user information in the same table. A safer way to do this might be (in pseudo-DDL): Table LoginCredentials ( int login_id PRIMARY KEY, char[] username UNIQUE, char[] password_hash ) Table UserInfo ( int user_id PRIMARY KEY, char[] name, char[] emailaddress . . . ) Table LoginToUser ( int login_id, int user_id ) Now, you can add rows for both username=username AND username=email address to the LoginCredentials table, use a much simpler query to log them in, and then retrieve their personal info through the LoginCredentials -> LoginToUser -> UserInfo join. This isn't perfectly normalized, since email address is stored twice, but since you are overloading the purpose of email address anyway, it may be a better model for you. It also solves the original problem, since there is only one unique column. TK -----Original Message----- From: Johannes Erdfelt [mailto:johannes@erdfelt.com] Sent: Thursday, October 10, 2002 2:58 PM To: db-sig@python.org Subject: Re: [DB-SIG] Portable method of determining which column wasn't unique? On Thu, Oct 10, 2002, Bob Gailer wrote: > At 02:52 PM 10/10/2002 -0400, you wrote: > > > I have a table which has multiple unique columns on it. My problem > > is that > > when I insert a row which violates the unique restraint, I can't figure out > > which column caused the problem. > > Just a stab in the dark - but I am suspicious of a data model that > requires > unique values in two (or more) columns. Can you verify that this is really > needed?. Yes. The two values are a username and an email address. username is unique for obvious reasons and the email address is unique because it provides an alternate means of logging in. > Also are the users of the system providing these values directly? Yes. The user chooses their own username and their email addres is their own. > You could : > select * from table where unique-column1 = proposed-new-value1 > select * from table where unique-column2 = proposed-new-value2 If > you get a row in either case then you know the corresponding new > value's already in use, That has the same races as the possible solution I came up with that I described at the end of my original email. Another insert came come in between the select and the insert. I was hoping to make this efficient and not require explicitly locking the table since the table receives queries often. I was also hoping to keep it portable across multiple databases (hence the relevance to db-sig) JE _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From johannes@erdfelt.com Thu Oct 10 21:17:38 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 10 Oct 2002 16:17:38 -0400 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: ; from dustin+pydbsig@spy.net on Thu, Oct 10, 2002 at 01:08:11PM -0700 References: <20021010155732.A4680@sventech.com> Message-ID: <20021010161738.B4680@sventech.com> It still doesn't tell me which one was taken. Just that one of them was. In this case it's the difference between just informing them that they need to pick a different username, or helping them find the other account they created. JE On Thu, Oct 10, 2002, Dustin Sallings wrote: > Around 15:57 on Oct 10, 2002, Johannes Erdfelt said: > > The correct way to do it is to have a unique index that spans > those two columns. If your insert fails, the name's taken. > > # On Thu, Oct 10, 2002, Bob Gailer wrote: > # > At 02:52 PM 10/10/2002 -0400, you wrote: > # > > # > > I have a table which has multiple unique columns on it. My problem is that > # > > when I insert a row which violates the unique restraint, I can't figure out > # > > which column caused the problem. > # > > # > Just a stab in the dark - but I am suspicious of a data model that requires > # > unique values in two (or more) columns. Can you verify that this is really > # > needed?. > # > # Yes. The two values are a username and an email address. > # > # username is unique for obvious reasons and the email address is unique > # because it provides an alternate means of logging in. > # > # > Also are the users of the system providing these values directly? > # > # Yes. The user chooses their own username and their email addres is their > # own. > # > # > You could : > # > select * from table where unique-column1 = proposed-new-value1 > # > select * from table where unique-column2 = proposed-new-value2 > # > If you get a row in either case then you know the corresponding new value's > # > already in use, > # > # That has the same races as the possible solution I came up with that I > # described at the end of my original email. > # > # Another insert came come in between the select and the insert. > # > # I was hoping to make this efficient and not require explicitly locking > # the table since the table receives queries often. > # > # I was also hoping to keep it portable across multiple databases (hence > # the relevance to db-sig) > # > # JE > # > # > # _______________________________________________ > # DB-SIG maillist - DB-SIG@python.org > # http://mail.python.org/mailman/listinfo/db-sig > # > # > > -- > SPY My girlfriend asked me which one I like better. > pub 1024/3CAE01D5 1994/11/03 Dustin Sallings > | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE > L_______________________ I hope the answer won't upset her. ____________ > From chris@cogdon.org Thu Oct 10 21:21:38 2002 From: chris@cogdon.org (Chris Cogdon) Date: Thu, 10 Oct 2002 13:21:38 -0700 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: Message-ID: On Thursday, Oct 10, 2002, at 13:08 US/Pacific, Dustin Sallings wrote: > Around 15:57 on Oct 10, 2002, Johannes Erdfelt said: > > The correct way to do it is to have a unique index that spans > those two columns. If your insert fails, the name's taken. There ARE circumstances where you have two columns that are independent, but need to be unique. For example, imagine a table of Artists. Amongst other information, one column represents the login name used by the artist to identify himself (or herself) to the system. Another column is the 'gallery name' used to present the artist to the outside world. Both columns need to be unique, as you cannot have two login names, nor two gallery names, that are the same. But the two are definitely independent. Postgresql, for example, will tell you the column name that is causing the problem as the value to the exception. Its embedded in a bunch of text, so you may have to do some text parsing to get the error message out. Other DBMSs ... .who knows? :) So... the answer is... it's not portable, but should be easily containable. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From dustin+pydbsig@spy.net Thu Oct 10 21:24:44 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 10 Oct 2002 13:24:44 -0700 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <20021010161738.B4680@sventech.com> Message-ID: Around 16:17 on Oct 10, 2002, Johannes Erdfelt said: # It still doesn't tell me which one was taken. Just that one of them was. # # In this case it's the difference between just informing them that they # need to pick a different username, or helping them find the other # account they created. Oh, sorry, missed the point. :) At the point where you get an exception on insert, you can do something like this: select username, email from users where username = ? or email = ? And do the comparison in the exception handler. This assumes, of course that it *is* an exceptional state (i.e. people *usually* don't try to get usernames that already exist, or share the same email address with lots of other users). # JE # # On Thu, Oct 10, 2002, Dustin Sallings wrote: # > Around 15:57 on Oct 10, 2002, Johannes Erdfelt said: # > # > The correct way to do it is to have a unique index that spans # > those two columns. If your insert fails, the name's taken. # > # > # On Thu, Oct 10, 2002, Bob Gailer wrote: # > # > At 02:52 PM 10/10/2002 -0400, you wrote: # > # > # > # > > I have a table which has multiple unique columns on it. My problem is that # > # > > when I insert a row which violates the unique restraint, I can't figure out # > # > > which column caused the problem. # > # > # > # > Just a stab in the dark - but I am suspicious of a data model that requires # > # > unique values in two (or more) columns. Can you verify that this is really # > # > needed?. # > # # > # Yes. The two values are a username and an email address. # > # # > # username is unique for obvious reasons and the email address is unique # > # because it provides an alternate means of logging in. # > # # > # > Also are the users of the system providing these values directly? # > # # > # Yes. The user chooses their own username and their email addres is their # > # own. # > # # > # > You could : # > # > select * from table where unique-column1 = proposed-new-value1 # > # > select * from table where unique-column2 = proposed-new-value2 # > # > If you get a row in either case then you know the corresponding new value's # > # > already in use, # > # # > # That has the same races as the possible solution I came up with that I # > # described at the end of my original email. # > # # > # Another insert came come in between the select and the insert. # > # # > # I was hoping to make this efficient and not require explicitly locking # > # the table since the table receives queries often. # > # # > # I was also hoping to keep it portable across multiple databases (hence # > # the relevance to db-sig) # > # # > # JE # > # # > # # > # _______________________________________________ # > # DB-SIG maillist - DB-SIG@python.org # > # http://mail.python.org/mailman/listinfo/db-sig # > # # > # # > # > -- # > SPY My girlfriend asked me which one I like better. # > pub 1024/3CAE01D5 1994/11/03 Dustin Sallings # > | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE # > L_______________________ I hope the answer won't upset her. ____________ # > # # _______________________________________________ # DB-SIG maillist - DB-SIG@python.org # http://mail.python.org/mailman/listinfo/db-sig # # -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From magnus@thinkware.se Thu Oct 10 21:30:23 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Thu, 10 Oct 2002 22:30:23 +0200 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <20021010155732.A4680@sventech.com> References: <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> <20021010145213.H3834@sventech.com> <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> Message-ID: <5.1.0.14.0.20021010222533.03104140@www.thinkware.se> At 15:57 2002-10-10 -0400, Johannes Erdfelt wrote: >That has the same races as the possible solution I came up with that I >described at the end of my original email. I was about to say that there is no race condition here in in SQL if you have high enough isolation level, but then I realize that you use MySQL... I think you need to use a RDBMS that handles transactions as SQL requires to be safe here, i.e. almost anything but MySQL, or even MySQL if you use transaction aware tables. (I'm not enough of an expert on MySQL to be sure that they really handle ACID properly...) --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From dustin+pydbsig@spy.net Thu Oct 10 21:28:46 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 10 Oct 2002 13:28:46 -0700 Subject: [DB-SIG] Portable method of determining which column wasn't u nique? In-Reply-To: <9B8090A2F0EBDB4ABD59B08E81C1A6842F6650@osi-postal.osi.ad.ea.com> Message-ID: Around 15:08 on Oct 10, 2002, Keating, Tim said: # A better way to deal with this might be to break up your tables along # functional lines. Right now it sounds like you are trying to store login # credentials and user information in the same table. A safer way to do # this might be (in pseudo-DDL): I don't think this line is completely clear. You'll find many places where username, credentials, and other user information are all contained. LDAP, old-school UNIX auth, NetInfo, and many apps that I've written. If you consider the table user-specific information, it makes sense to keep it all together. If a user will always have one set of credentials and one set of information (name, etc...), then there's no point of having two tables where a row in one guarantees both a row in the other and a row in a mapping table hooking the two together. There certainly are cases where it makes sense to separate such things, but I don't think they're very common. # Table LoginCredentials ( # int login_id PRIMARY KEY, # char[] username UNIQUE, # char[] password_hash # ) # # Table UserInfo ( # int user_id PRIMARY KEY, # char[] name, # char[] emailaddress # . # . # . # ) # # Table LoginToUser ( # int login_id, # int user_id # ) # # Now, you can add rows for both username=username AND username=email address # to the LoginCredentials table, use a much simpler query to log them in, and # then retrieve their personal info through the LoginCredentials -> # LoginToUser -> UserInfo join. # # This isn't perfectly normalized, since email address is stored twice, but # since you are overloading the purpose of email address anyway, it may be a # better model for you. It also solves the original problem, since there is # only one unique column. # # TK # # -----Original Message----- # From: Johannes Erdfelt [mailto:johannes@erdfelt.com] # Sent: Thursday, October 10, 2002 2:58 PM # To: db-sig@python.org # Subject: Re: [DB-SIG] Portable method of determining which column wasn't # unique? # # # On Thu, Oct 10, 2002, Bob Gailer wrote: # > At 02:52 PM 10/10/2002 -0400, you wrote: # > # > > I have a table which has multiple unique columns on it. My problem # > > is that # > > when I insert a row which violates the unique restraint, I can't figure # out # > > which column caused the problem. # > # > Just a stab in the dark - but I am suspicious of a data model that # > requires # > unique values in two (or more) columns. Can you verify that this is really # # > needed?. # # Yes. The two values are a username and an email address. # # username is unique for obvious reasons and the email address is unique # because it provides an alternate means of logging in. # # > Also are the users of the system providing these values directly? # # Yes. The user chooses their own username and their email addres is their # own. # # > You could : # > select * from table where unique-column1 = proposed-new-value1 # > select * from table where unique-column2 = proposed-new-value2 If # > you get a row in either case then you know the corresponding new # > value's already in use, # # That has the same races as the possible solution I came up with that I # described at the end of my original email. # # Another insert came come in between the select and the insert. # # I was hoping to make this efficient and not require explicitly locking the # table since the table receives queries often. # # I was also hoping to keep it portable across multiple databases (hence the # relevance to db-sig) # # JE # # # _______________________________________________ # DB-SIG maillist - DB-SIG@python.org # http://mail.python.org/mailman/listinfo/db-sig # # _______________________________________________ # DB-SIG maillist - DB-SIG@python.org # http://mail.python.org/mailman/listinfo/db-sig # # -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From johannes@erdfelt.com Thu Oct 10 21:41:49 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 10 Oct 2002 16:41:49 -0400 Subject: [DB-SIG] Portable method of determining which column wasn't u nique? In-Reply-To: <9B8090A2F0EBDB4ABD59B08E81C1A6842F6650@osi-postal.osi.ad.ea.com>; from TKeating@origin.ea.com on Thu, Oct 10, 2002 at 03:08:53PM -0500 References: <9B8090A2F0EBDB4ABD59B08E81C1A6842F6650@osi-postal.osi.ad.ea.com> Message-ID: <20021010164149.C4680@sventech.com> On Thu, Oct 10, 2002, Keating, Tim wrote: > A better way to deal with this might be to break up your tables along > functional lines. Right now it sounds like you are trying to store login > credentials and user information in the same table. A safer way to do this > might be (in pseudo-DDL): > > Table LoginCredentials ( > int login_id PRIMARY KEY, > char[] username UNIQUE, > char[] password_hash > ) > > Table UserInfo ( > int user_id PRIMARY KEY, > char[] name, > char[] emailaddress > . > . > . > ) > > Table LoginToUser ( > int login_id, > int user_id > ) > > Now, you can add rows for both username=username AND username=email address > to the LoginCredentials table, use a much simpler query to log them in, and > then retrieve their personal info through the LoginCredentials -> > LoginToUser -> UserInfo join. > > This isn't perfectly normalized, since email address is stored twice, but > since you are overloading the purpose of email address anyway, it may be a > better model for you. It also solves the original problem, since there is > only one unique column. And then I can assume any error that violates a unique constraint must be the one unique column. This is an interesting idea and looks like it would functionally work, assuming transactions are used. I do use transactions and it would be a reasonable requirement for the software I'm writing. It's a little bit more complicated than I would have liked, but it's not ugly and I think should be portable. Thanks for the idea. JE From johannes@erdfelt.com Thu Oct 10 21:51:07 2002 From: johannes@erdfelt.com (Johannes Erdfelt) Date: Thu, 10 Oct 2002 16:51:07 -0400 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <5.1.0.14.0.20021010222533.03104140@www.thinkware.se>; from magnus@thinkware.se on Thu, Oct 10, 2002 at 10:30:23PM +0200 References: <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> <20021010145213.H3834@sventech.com> <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> <20021010155732.A4680@sventech.com> <5.1.0.14.0.20021010222533.03104140@www.thinkware.se> Message-ID: <20021010165107.D4680@sventech.com> On Thu, Oct 10, 2002, Magnus Lycka wrote: > At 15:57 2002-10-10 -0400, Johannes Erdfelt wrote: > >That has the same races as the possible solution I came up with that I > >described at the end of my original email. > > I was about to say that there is no race > condition here in in SQL if you have high > enough isolation level, but then I realize > that you use MySQL... > > I think you need to use a RDBMS that handles > transactions as SQL requires to be safe here, > i.e. almost anything but MySQL, or even MySQL > if you use transaction aware tables. (I'm not > enough of an expert on MySQL to be sure that > they really handle ACID properly...) But why carry around the transaction baggage when the information is available? It does tell me what key caused the problem and I'm sure there's some place to get the information to put all of the pieces together. Although, looking at some of the other databases, this doesn't look like it'll be portable at all. The details on the backend seem to vary enough that an abstracted API may be unreasonable or just not worth it. And yes, MySQL is ACID compliant for certain table types (InnoDB for one). JE From magnus@thinkware.se Fri Oct 11 17:48:43 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Fri, 11 Oct 2002 18:48:43 +0200 Subject: [DB-SIG] SQL Relay Message-ID: <5.1.0.14.0.20021011184316.03168d90@www.thinkware.se> Does anyone here have experience of SQL Relay. It seems like a clever concept to me, and it has a DB API interface: http://www.firstworks.com/sqlrelay/programming/pythondb.html It's not listed in http://www.python.org/topics/database/modules.html though, and I rarely see it mentioned. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From ramrom@earthling.net Fri Oct 11 20:20:56 2002 From: ramrom@earthling.net (Bob Gailer) Date: Fri, 11 Oct 2002 13:20:56 -0600 Subject: [DB-SIG] SQL Relay In-Reply-To: <5.1.0.14.0.20021011184316.03168d90@www.thinkware.se> Message-ID: <5.1.0.14.0.20021011131923.02d20488@pop.viawest.net> --=======12F73FCF======= Content-Type: multipart/alternative; x-avg-checked=avg-ok-5A621474; boundary="=====================_760914==_.ALT" --=====================_760914==_.ALT Content-Type: text/plain; x-avg-checked=avg-ok-5A621474; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 06:48 PM 10/11/2002 +0200, Magnus Lycka wrote: > SQL Relay ... seems like a clever concept to me >http://www.firstworks.com/sqlrelay/programming/pythondb.html I just looked at the link. I fail to see what is special about SQL Relay. Please educate me. Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --=====================_760914==_.ALT Content-Type: text/html; x-avg-checked=avg-ok-5A621474; charset=us-ascii Content-Transfer-Encoding: 8bit At 06:48 PM 10/11/2002 +0200, Magnus Lycka wrote:
 SQL Relay ... seems like a clever concept to me
http://www.firstworks.com/sqlrelay/programming/pythondb.html

I just looked at the link. I fail to see what is special about SQL Relay. Please educate me.

Bob Gailer
mailto:ramrom@earthling.net
303 442 2625
--=====================_760914==_.ALT-- --=======12F73FCF=======-- From bsb@xlab.net Sun Oct 13 14:03:49 2002 From: bsb@xlab.net (Siggy Brentrup) Date: Sun, 13 Oct 2002 15:03:49 +0200 Subject: [DB-SIG] Apology for accidental spamming :-( Message-ID: Hello, in an attempt to transfer the contents of a mailbox to another location, I made a big mistake resulting in a lot of messages being resent to their original receipients. Please kindly accept my apologies, it will not happen again. Siggy Brentrup ------------------------------ Log entries for messages erroneously sent to you: 2002-10-13 13:49:52 180hFI-0001Tc-00 => db-sig@python.org R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:55 180hFI-0001Ta-00 => db-sig@python.org R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29] From jno@glasnet.ru Mon Oct 14 08:24:51 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Mon, 14 Oct 2002 11:24:51 +0400 Subject: [DB-SIG] Portable method of determining which column wasn't unique? In-Reply-To: <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> References: <20021010145213.H3834@sventech.com> <5.1.0.14.0.20021010134314.02d5b008@pop.viawest.net> Message-ID: <20021014072451.GB14540@glas.net> On Thu, Oct 10, 2002 at 01:48:24PM -0600, Bob Gailer wrote: > You could : > select * from table where unique-column1 = proposed-new-value1 > select * from table where unique-column2 = proposed-new-value2 select count(*) from table where unique-column1 = proposed-new-value1 select count(*) from table where unique-column2 = proposed-new-value2 would be a bit more "portable" (or just handy). it will return always integer non-null value. -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From magnus@thinkware.se Tue Oct 15 14:34:39 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 15 Oct 2002 15:34:39 +0200 Subject: [DB-SIG] SQL Relay In-Reply-To: <5.1.0.14.0.20021011131923.02d20488@pop.viawest.net> References: <5.1.0.14.0.20021011184316.03168d90@www.thinkware.se> Message-ID: <5.1.0.14.0.20021015145348.02b4ce98@www.thinkware.se> At 13:20 2002-10-11 -0600, Bob Gailer wrote: >At 06:48 PM 10/11/2002 +0200, Magnus Lycka wrote: >> SQL Relay ... seems like a clever concept to me >>http://www.firstworks.com/sqlrelay/programming/pythondb.html > >I just looked at the link. I fail to see what is special about SQL Relay.= =20 >Please educate me. For general info on SQL Relay, it's better to go up a few steps to http://www.firstworks.com/sqlrelay/ But understand me right. I'm not trying to promote the product. I'm just asking about it. (Even if I forgot a question mark.) As far as I understand, using the SQL Relay and either of its python drivers (DB API or non-standard), you can access ODBC, Oracle, MySQL, mSQL, PostgreSQL, Sybase, IBM DB2, Interbase, Lago (whatever that is) and SQLite. You just need one python driver for this! This could make it into an option for those who would use mxODBC but have problems with its license. (Of course, SQL Relay being GPL might also be a complication for some, but at least it's permitted to make money on contracting jobs with SQL Relay without a paid licence.) SQL Relay also provides connection pooling, proxying and load balancing. It works with Unix and Linux. It's a bit surprising to me that it's not discussed here more, and that it's not listed in the module list. Is it perhaps not as good as it sounds? That's why I ask... --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From ramrom@earthling.net Tue Oct 15 14:32:38 2002 From: ramrom@earthling.net (Bob Gailer) Date: Tue, 15 Oct 2002 07:32:38 -0600 Subject: [DB-SIG] SQL Relay In-Reply-To: <5.1.0.14.0.20021015145348.02b4ce98@www.thinkware.se> References: <5.1.0.14.0.20021011131923.02d20488@pop.viawest.net> <5.1.0.14.0.20021011184316.03168d90@www.thinkware.se> Message-ID: <5.1.0.14.0.20021015073040.022c07d0@66.28.54.253> --=======5B6D5048======= Content-Type: text/plain; x-avg-checked=avg-ok-2D1F7CA8; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 03:34 PM 10/15/2002 +0200, Magnus Lycka wrote: >For general info on SQL Relay, it's better to go up a few steps to >http://www.firstworks.com/sqlrelay/ Thanks; that helps a lot. Unfortunately for me I'm working in Windows right now; SQL Relay is for Linux. I hope I soon can kick the W* habit. Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --=======5B6D5048=======-- From mal@lemburg.com Tue Oct 15 20:05:03 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 15 Oct 2002 21:05:03 +0200 Subject: [DB-SIG] SQL Relay References: <5.1.0.14.0.20021011184316.03168d90@www.thinkware.se> <5.1.0.14.0.20021015145348.02b4ce98@www.thinkware.se> Message-ID: <3DAC66DF.10807@lemburg.com> Magnus Lycka wrote: > At 13:20 2002-10-11 -0600, Bob Gailer wrote: > >> At 06:48 PM 10/11/2002 +0200, Magnus Lycka wrote: >> >>> SQL Relay ... seems like a clever concept to me >>> http://www.firstworks.com/sqlrelay/programming/pythondb.html >> >> >> I just looked at the link. I fail to see what is special about SQL >> Relay. Please educate me. > > For general info on SQL Relay, it's better to go up a > few steps to http://www.firstworks.com/sqlrelay/ Hmm, the "Getting Started With Databases" is a good source of information for setting up databases. It has quite a few hints to common gotchas which are hard to find otherwise. > But understand me right. I'm not trying to promote the > product. I'm just asking about it. (Even if I forgot a > question mark.) > > As far as I understand, using the SQL Relay and either of > its python drivers (DB API or non-standard), you can access > ODBC, Oracle, MySQL, mSQL, PostgreSQL, Sybase, IBM DB2, > Interbase, Lago (whatever that is) and SQLite. You just need > one python driver for this! This could make it into an option > for those who would use mxODBC but have problems with its > license. (Of course, SQL Relay being GPL might also be a > complication for some, but at least it's permitted to make > money on contracting jobs with SQL Relay without a paid > licence.) > > SQL Relay also provides connection pooling, proxying and > load balancing. It works with Unix and Linux. > > It's a bit surprising to me that it's not discussed here > more, and that it's not listed in the module list. Is it > perhaps not as good as it sounds? > > That's why I ask... Perhaps because SQL Relay is crafted towards CGI web-applications which work on small result sets ? E.g. caching complete result sets is not always what you'd want in a GUI-based application. However, it may be a good alternative for those who want to access Oracle from platforms for which there are no Oracle client libs available. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From eivindt-db-sig@multinet.no Wed Oct 16 12:56:28 2002 From: eivindt-db-sig@multinet.no (Eivind Tagseth) Date: Wed, 16 Oct 2002 13:56:28 +0200 Subject: [DB-SIG] How to *you* access your database objects? Message-ID: <20021016115627.GD29525@tagseth-trd.consultit.no> I'm new to this list, so I apologize if this subject has been discussed before. I'm not asking how to use the DB-API, that's pretty straight forward and well documentet. But what do you actually do with the data you retrieve. And how do you retrieve it? Personally, I think it makes sense to create a python class for each database table I have, and make the entity attributes available as a dictionary. I think this is cleaner than directly accessing attributes and more convenient than adding getters and setters as one would do in e.g. Java. For example, a class for a Tool-entity may look like this: ----------------8<----------8<-------------8<---------------8<------------ from UserDict import UserDict class Tool (UserDict): datatypes = { "id":"number", "Name":"varchar", "URL":"varchar", "Description":"varchar" } def __init__(self): self.data = { "id":None, "Name":None, "URL":None, "Description":None } def __setitem__(self, name, value): if name not in self.keys(): raise KeyError("This object does not support the key %s" % name) UserDict.__setitem__(self, name, value) ----------------8<----------8<-------------8<---------------8<------------ It seems to work pretty well, but I haven't had a chance to put a lot of thought into it yet. What do other people do? I'm not pleased with the Tool-class yet though. There is no mechanism for fetching rows from the database and returning these as Tool-objects, and there is no way to update or insert these back into the database. Do people have generalized patterns on how to do this? J2EE has special objects called Entity objects which solves this problem. Creating a new EntityObject() actually inserts that object into the database, and deleting the EntityObject removes it. Would it make sense to expand my Tool class to have methods for inserting, updating, deleting and finding the object in the database with SQL-commands? I thought about creating a method like: ---------------8<-----------8<----------8<-------------8<-------------8<----- def findById(self, id): self._dbi.execute("SELECT %s FROM %s WHERE id = %s" % ( ", ".join(self.keys()), "Tool", id)) data = self._dbi.fetchone() if not data: return None obj = self i = 0 for k in self.keys(): obj[k] = data[i] i = i + 1 return obj -------------8<--------------8<---------------8<-------------8<-------------- It shouldn't be very hard to generalize this further, and be able to define an python class for accessing a database table just be registering information about attributes, datatypes and primary keys. I'm sure I'm not the first one to think about this. What are other people doing? What's braindead about my way? Comments? Eivind -- Eivind Tagseth, E-mail jobb: eivind.tagseth@consultit.no, E-mail priv: eivindt@multinet.no Mobil: +47 922 43742 From jacobs@penguin.theopalgroup.com Wed Oct 16 13:19:46 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Wed, 16 Oct 2002 08:19:46 -0400 (EDT) Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: <20021016115627.GD29525@tagseth-trd.consultit.no> Message-ID: On Wed, 16 Oct 2002, Eivind Tagseth wrote: > But what do you actually do with the data you retrieve. And how do you > retrieve it? A simple question... a rather long and complex answer. We use the following components: 1) A database row object that supports tuple, dictionary and object-like access. It is implemented without allocating a dictionary per-object using some of the new Python 2.2 (and 2.3) features. See 'dbrow' on http://opensource.theopalgroup.com/ for details on a very early version of this concept. Our current version has evolved far beyond that, and is implemented in both Python and as a C extension module, so there is effectively no performance hit compared to returning rows as tuples. 2) A connection configuration and abstraction layer, that allows the creation of database connections to various backend drivers with common connection arguments (since DB-API does not fully specify this). 3) A low-level backend abstraction layer that implements per-connection primitives for SQL literal and identifier escaping, date formatting and conversion, and type mapping. 4) A high-level SQL dialect re-writer that can translate one SQL dialect to another via a source-to-source transformation. e.g., MS SQL <-> Oracle <-> Sybase <-> PostgreSQL. 5) Intelligent caching objects that can handle simple queries directly from cache, if present, and forward them to the database backend if not. ...plus a lot more... If you haven't guessed, our systems have to be very sociable with dozens of diverse database backends, and switch very naturally between them. > Personally, I think it makes sense to create a python class for each > database table I have, and make the entity attributes available as a > dictionary. I think this is cleaner than directly accessing attributes > and more convenient than adding getters and setters as one would do in > e.g. Java. We use meta-class constructors to build these 'per-table' (or result schema) object types. They use our database introspection layer to dynamically build the field names and types. Just food for thought... we're still working on making as much of this framework available as open source, though it has been slow going due to the massive volume of paying work I have to do. Best regards, -Kevin Jacobs -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From eivindt@multinet.no Wed Oct 16 14:29:29 2002 From: eivindt@multinet.no (Eivind Tagseth) Date: Wed, 16 Oct 2002 15:29:29 +0200 Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: References: <20021016115627.GD29525@tagseth-trd.consultit.no> Message-ID: <20021016132929.GE29525@tagseth-trd.consultit.no> * Kevin Jacobs [021016 12:20]: > On Wed, 16 Oct 2002, Eivind Tagseth wrote: > > But what do you actually do with the data you retrieve. And how do you > > retrieve it? > > A simple question... a rather long and complex answer. > > We use the following components: > > 1) A database row object that supports tuple, dictionary and object-like > access. It is implemented without allocating a dictionary per-object > using some of the new Python 2.2 (and 2.3) features. See 'dbrow' on > > http://opensource.theopalgroup.com/ > > for details on a very early version of this concept. Our current > version has evolved far beyond that, and is implemented in both Python > and as a C extension module, so there is effectively no performance > hit compared to returning rows as tuples. Great stuff. This fits quite well into my line of thought as well, and exchanging my UserDict-based class with db_row was really simple. The db_row-generated classes works pretty much like a dictionary (i.e. I can to object['attribute']), but not completely. Is there any special reason why not all dictionary methods are compatible with dictionaries? That is, why _items(), _keys(), _values() and _has_key() rather than items(), keys(), values() and has_key()? Eivind From jacobs@penguin.theopalgroup.com Wed Oct 16 14:40:48 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Wed, 16 Oct 2002 09:40:48 -0400 (EDT) Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: <20021016132929.GE29525@tagseth-trd.consultit.no> Message-ID: On Wed, 16 Oct 2002, Eivind Tagseth wrote: > * Kevin Jacobs [021016 12:20]: > > On Wed, 16 Oct 2002, Eivind Tagseth wrote: > > > But what do you actually do with the data you retrieve. And how do you > > > retrieve it? > > > > A simple question... a rather long and complex answer. > > > > We use the following components: > > > > 1) A database row object that supports tuple, dictionary and object-like > > access. It is implemented without allocating a dictionary per-object > > using some of the new Python 2.2 (and 2.3) features. See 'dbrow' on > > > > http://opensource.theopalgroup.com/ > > > > for details on a very early version of this concept. Our current > > version has evolved far beyond that, and is implemented in both Python > > and as a C extension module, so there is effectively no performance > > hit compared to returning rows as tuples. > > Great stuff. This fits quite well into my line of thought as well, and > exchanging my UserDict-based class with db_row was really simple. > > The db_row-generated classes works pretty much like a dictionary > (i.e. I can to object['attribute']), but not completely. Is there any > special reason why not all dictionary methods are compatible with > dictionaries? That is, why _items(), _keys(), _values() and _has_key() > rather than items(), keys(), values() and has_key()? That old version of db_row renames the dictionary methods to avoid namespace collisions with fields named 'keys', 'values', etc. Our new db_row implementation is restructured as follows: R = db_row.IRowMetaClass( ('a','b','c') ) row = R( (1,2,3) ) # Dict like access row['a'] row['A'] # case-insensitive access row.keys() row.items() row.has_key('a') for 'a' in row: ... # Tuple like access row[1] row[-1] row[0:2] # returns a tuple row[:] # returns a tuple # Object like access (this is different from the older implementation) row.fields.a row.fields.A # case-insensitive access row.fields.B If you are interested, I'll spend some time and package our current version and make it available on opensource.theopalgroup.com. It can be used in two modes: 1) as portable pure-python or 2) augmented with an optional C extension module (tested with Python 2.2.1 and 2.2.2 and recent 2.3 CVS versions). Regards, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From gerhard.haering@opus-gmbh.net Wed Oct 16 14:52:13 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Wed, 16 Oct 2002 13:52:13 +0000 (UTC) Subject: [DB-SIG] Re: How to *you* access your database objects? References: <20021016132929.GE29525@tagseth-trd.consultit.no> Message-ID: Kevin Jacobs [2002-10-16 13:40 GMT]: > [new dbrow] > If you are interested, I'll spend some time and package our current version > and make it available on opensource.theopalgroup.com. I'd be interested, too. > It can be used in two modes: 1) as portable pure-python or 2) augmented with > an optional C extension module (tested with Python 2.2.1 and 2.2.2 and recent > 2.3 CVS versions). And especially in the C version :) -- Gerhard From jacobs@penguin.theopalgroup.com Wed Oct 16 17:31:50 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Wed, 16 Oct 2002 12:31:50 -0400 (EDT) Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: <20021016134629.GF29525@tagseth-trd.consultit.no> Message-ID: On Wed, 16 Oct 2002, Eivind Tagseth wrote: > > If you are interested, I'll spend some time and package our current version > > and make it available on opensource.theopalgroup.com. It can be used in two > > modes: 1) as portable pure-python or 2) augmented with an optional C > > extension module (tested with Python 2.2.1 and 2.2.2 and recent 2.3 CVS > > versions). > > I'm definately interested, but it's not time critical, so please do it when > you have time, not before. ;) Eivind, Gerhard, and anyone else who is interested.. I've just released a totally re-written db_row implementation that I mentioned in my previous DB-SIG mail. It implements much cleaner dictionary, tuple, and object-like semantics and includes an optional C extension module for speed. I've not written much documentation for it, though the source if fairly clean and has a fair amount of inline documentation. You can get it from: http://opensource.theopalgroup.com/ Please let me know what you think. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From eivindt@multinet.no Thu Oct 17 12:06:18 2002 From: eivindt@multinet.no (Eivind Tagseth) Date: Thu, 17 Oct 2002 13:06:18 +0200 Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: References: <20021016134629.GF29525@tagseth-trd.consultit.no> Message-ID: <20021017110616.GI29525@tagseth-trd.consultit.no> * Kevin Jacobs [021016 16:32]: > Eivind, Gerhard, and anyone else who is interested.. I've just released a > totally re-written db_row implementation that I mentioned in my previous > DB-SIG mail. It implements much cleaner dictionary, tuple, and object-like > semantics and includes an optional C extension module for speed. I've not > written much documentation for it, though the source if fairly clean and has > a fair amount of inline documentation. > Please let me know what you think. Seems to be working just fine, and now I can pretend that my MetaRows are dictionaries as well. The only feature that disappeared as far as I can see is that you can now do: obj = db_row.MetaRow(('a','b','c'))((1,2,3)) obj['doesnotexist'] = 5 obj.fields.doesnotexist = 6 Without errors. I was able to fix the first one myself, but the fields-version is a bit over my head I'm afraid. BTW: This applies to the python version, not tried installing the C version yet. Eivind From jacobs@penguin.theopalgroup.com Thu Oct 17 15:24:11 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 17 Oct 2002 10:24:11 -0400 (EDT) Subject: [DB-SIG] How to *you* access your database objects? In-Reply-To: <20021017110616.GI29525@tagseth-trd.consultit.no> Message-ID: On Thu, 17 Oct 2002, Eivind Tagseth wrote: > * Kevin Jacobs [021016 16:32]: > > Eivind, Gerhard, and anyone else who is interested.. I've just released a > > totally re-written db_row implementation that I mentioned in my previous > > DB-SIG mail. It implements much cleaner dictionary, tuple, and object-like > > semantics and includes an optional C extension module for speed. I've not > > written much documentation for it, though the source if fairly clean and has > > a fair amount of inline documentation. > > > Please let me know what you think. > > Seems to be working just fine, and now I can pretend that my MetaRows are > dictionaries as well. The only feature that disappeared as far as I can > see is that you can now do: > > obj = db_row.MetaRow(('a','b','c'))((1,2,3)) > > obj['doesnotexist'] = 5 > obj.fields.doesnotexist = 6 > > Without errors. Good catch! This was a flaw in only the Python version, and it has been corrected. I've release db_row version 0.6alpha, which can be found at: http://opensource.theopalgroup.com Here is the complete ChangeLog: Changes from version 0.5 -> 0.6: o Added missing slots declaration from Python FieldsBase object. This corrected a major flaw in the pure-Python implementation which caused the allocation of per-instance dictionaries, and allowing access to undeclared fields. The C version of FieldsBase was not affected. o Fixed exception types so that various accessors raise the appropriate exceptions. e.g., previously __getitem__ would incorrectly raise AttributeError exceptions. These changes were made in both the Python and C versions. o Added many new test cases to the regression suite, including much more rigorous read/write testing. o Removed some unnecessary (and slow!) code from the C fields_subscript function. I suspect it was a left-over from past debugging that was not completely removed. Regards, -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From sunita@cybage.com Mon Oct 21 13:05:53 2002 From: sunita@cybage.com (Sunita Pawar) Date: Mon, 21 Oct 2002 17:35:53 +0530 Subject: [DB-SIG] DCOracle - oci.error to access Message-ID: <047101c278fa$34b06dd0$d302a8c0@cybageroute> This is a multi-part message in MIME format. ------=_NextPart_000_046E_01C27928.4E31BB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, How do I look at the error that was returned in the try/except for = DCOracle=20 I had tried import DCOracle try: db =3D DCOracle.Connect(user/password@sid) except oci.error, e: print "Error", e But it gives the error message: NameError: oci Do I ahve to import some module to access oci? Even if I have to, how do = I access the what oci.error is? Thanks Sunita ------=_NextPart_000_046E_01C27928.4E31BB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
How do I look at the error that was returned in the try/except = for=20 DCOracle
I had tried
 
import DCOracle
try:
     db =3D DCOracle.Connect(user/password@sid)
except = oci.error,=20 e:
     print "Error", e
 
But it gives the error = message:
    NameError: = oci
 
Do I ahve to import some module to = access oci? Even=20 if I have to, how do I access the what oci.error is?
 
Thanks
Sunita
------=_NextPart_000_046E_01C27928.4E31BB50-- From matt@zope.com Mon Oct 21 15:02:51 2002 From: matt@zope.com (Matthew T. Kromer) Date: Mon, 21 Oct 2002 10:02:51 -0400 Subject: [DB-SIG] DCOracle - oci.error to access References: <047101c278fa$34b06dd0$d302a8c0@cybageroute> Message-ID: <3DB4090B.9080309@zope.com> Sunita Pawar wrote: > Hi, > > How do I look at the error that was returned in the try/except for > DCOracle > I had tried > > import DCOracle > try: > db = DCOracle.Connect(user/ > password@sid ) > except oci.error, e: > print "Error", e > > But it gives the error message: > NameError: oci > > Do I ahve to import some module to access oci? Even if I have to, how > do I access the what oci.error is? > > Thanks > Sunita Try using except DCOracle2.DatabaseError: instead. -- Matt Kromer Zope Corporation http://www.zope.com/ From plusk@RADFORD.EDU Fri Oct 18 21:59:51 2002 From: plusk@RADFORD.EDU (+ACI-Lusk, Paul D+ACI-) Date: Fri, 18 Oct 2002 16:59:51 -0400 Subject: [DB-SIG] More trouble with DCOracle2 on HPUX11I Message-ID: <78E14EC993154B4AA6D771902D2CAAAA1EA622@exchange.RADFORD.EDU> We are getting the following error message when trying to install: cc: +ACI-./dco2.c+ACI-, line 2894: warning 604: Pointers are not assignment-compatible. cc: +ACI-./dco2.c+ACI-, line 2894: warning 563: Argument +ACM-4 is not the correct type. cc: +ACI-./dco2.c+ACI-, line 4534: warning 604: Pointers are not assignment-compatible. cc: +ACI-./dco2.c+ACI-, line 4534: warning 563: Argument +ACM-2 is not the correct type. cc: +ACI-./dco2.c+ACI-, line 4813: warning 562: Redeclaration of +ACI-OracleDate+AF8-alloc+ACI- with a different storage class specifier: +ACI-OracleDate+AF8-alloc+ACI- will have internal linkage. cc: +ACI-./dco2.c+ACI-, line 5060: warning 604: Pointers are not assignment-compatible. cc: +ACI-./dco2.c+ACI-, line 5103: warning 604: Pointers are not assignment-compatible. cc: +ACI-./dco2.c+ACI-, line 6428: warning 562: Redeclaration of +ACI-trace+ACI- with a different storage class specifier: +ACI-trace+ACI- will have internal linkage. cc: +ACI-./dco2.c+ACI-, line 6483: warning 604: Pointers are not assignment-compatible. ld -b ./dco2.o -L/u01/app/oracle/product/9.2.0.1/lib/ -lclntsh -lcommon -lcore4 -lnlsrtl3 -o ./dco2.sl ld: Can't find library: +ACI-common+ACI- +ACoAKgAq- Error exit code 1 Stop. ---------------------- HPUX11I is 64 bit. Oracle is 64 bit, and we have Python 2.2.2 installed running 64 bit as well. The mx Base extensions installed okay (Thanks, Marc-Andre) and are working great. I think the missing library message is because we have Oracle 9 (9.2.0.1 to be precise). I think that the library names have changed and the equivalants to the one listed in the ld line are libcommon9, libcore9, and libnls9. But I would appreciate any advice on what to do to get DCOracle2 running. +AF8AXw- Paul D. Lusk Programmer plusk+AEA-radford.edu Radford University (540)831-6430 From ianb@colorstudy.com Tue Oct 22 01:55:21 2002 From: ianb@colorstudy.com (Ian Bicking) Date: 21 Oct 2002 19:55:21 -0500 Subject: [DB-SIG] [ANN] SQLObject 0.1 Message-ID: <1035248121.12706.127.camel@dsl-65-184-205-5.telocity.com> This is the first release of SQLObject (v0.1). SQLObject is an object-relational mapper. It's meant to make database rows look like normal Python objects -- no dictionary access, no distinguishing features between attributes derived from the row and attributes you define in your class definition. It also doesn't use any toolchain or code generation. It currently only supports MySQL, but I would like to support other databases (it should be easy). It makes some assumptions about your schema, but does not require anything novel. I would like to make it possible to use with any reasonable schema. This is an alpha-quality release -- an earlier version has been used significantly without issue, but this is a complete rewrite. It *does* have full documentation. You can find it at: http://colorstudy.com/software/python/SQLObject/ (I'm looking for some feedback before I announce this more widely) -- Ian Bicking Colorstudy Web Development ianb@colorstudy.com http://www.colorstudy.com 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 From bosahv@netscape.net Tue Oct 22 06:03:31 2002 From: bosahv@netscape.net (Bo Vandenberg) Date: Tue, 22 Oct 2002 05:03:31 +0000 (UTC) Subject: [DB-SIG] Simple Cookbook App Advice Message-ID: Hi, I'm grand spanking new to programming and python. That said, I've been looking at the books for a while and I want to start a project. This is basically my first project and little might come of it but here goes. If anything ever comes of it a GPL license...etc Stage 1 The idea is to parse a food recipe from a text file into a database. The files are all exports from the "Meal Menu" basic program. The initial platform will be Windows 2000. * Simple, Simple, Simple My thoughts right now are Gadfly and Spark. Simple Questions: 1) Would people mind if I posted questions to this list? - A Python DB will be central to the whole thing. - I will put "Cookbook" in the header if people think thats a good idea. 2) What do people think of the project? 3) Any advice? Any help, much appreciated. Bo From ianb@colorstudy.com Tue Oct 22 07:47:32 2002 From: ianb@colorstudy.com (Ian Bicking) Date: 22 Oct 2002 01:47:32 -0500 Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: References: Message-ID: <1035269252.533.199.camel@dsl-65-184-205-5.telocity.com> (Since I was writing this up I thought I might as well copy it to DB-SIG as well) On Tue, 2002-10-22 at 00:51, Steve Freitas wrote: > Could you illuminate for us the differences in > philosophy and applicability between SQLObject and MiddleKit? SQLObject and MiddleKit are basically trying to do the same thing -- both cache similarly, for instance, and neither deals with transactions. I think MK has some sense of committing changes -- I can't remember -- but SQLObject currently commits all changes immediately. But for the most part when using the objects (as opposed to defining them), MK and SQLObject should feel fairly similar -- the differences are more syntactic than semantic. I can't claim I ever really committed to using MK -- I played with it some, but that's all. But I did make SQLObject somewhat in response. I didn't like the way objects were defined in MK -- CSV files bug me, and in general I like Python and want to stick to Python. So you define the objects (table and column names, etc) just with some special class attributes. It uses some Python magic (metaclasses) to turn those into a fully-functional class definition. In contrast, MK uses code generation to pretty much the same effect. And my vague impression is that PyDO avoids all this trouble by using the dictionary interface, so it doesn't have to create methods for each column -- I specifically didn't want to do something like that, because I don't want the database columns to be distinguishable from other methods and attributes. Making that distinction, IMHO, is a significant compromise of the whole point of a middle object. Both SQLObject and MK should perform relatively similarly. SQLObject may be faster in some aspects (less function calls, for instance), but I would not be surprised if this difference was negligible. SQLObject does not do any data integrity checks, unlike MK. But you can use subclassing to do your own checks, just like in MK. In effect, you won't automatically catch a column being set to a non-integers despite its definition. In practice, SQL handles 10 just like '10', and gives the necessary errors if you pass a string that can't be coerced into an integer, so I wasn't very concerned. True error checking in both cases requires custom code (assuming your constraints aren't trivial). I suppose in more powerful databases you can use constraints in the database -- but again, that's up to you (as it should be). MK does schema generation. SQLObject deliberately does not; schema generation just didn't seem like a problem in need of solving to me. I also want to make as few requirements on the schema as possible. Both MK and SQLObject currently only work with MySQL. I hope to extend SQLObject, and I think it should be very easy (actually, I hope others will extend it, but I'll help them :). There's really only one part of SQLObject that need to be ported -- inserting a row, to be specific. SQLObject has an experimental feature for selecting multiple objects (i.e., generating a SELECT statement). I think it's clever and cute -- I'm not actually sure how useful it is. SQLObject also happens to use properties, as introduced in Python 2.2. Mostly because this is my first 2.2-specific code, and I thought I'd go all out. So you do things like "p.firstName" and "p.firstName = 'Joe'" instead of "p.firstName()" and "p.setFirstName('Joe')" like you would in MK. I think that's a fairly thorough explanation. MiddleKit is more mature, of course, and has thorough unit tests and all that good stuff. When you are actually using them, I think you'll find SQLObject is less formal and easier to experiment with. I wanted it to feel thinner, which I think it does. (It's also small enough that I don't feel entirely crazy when I fantasize about it becoming simply Correct, tests or no tests -- but it's not there yet, of course :) Ian From gerhard.haering@opus-gmbh.net Tue Oct 22 13:12:44 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Tue, 22 Oct 2002 12:12:44 +0000 (UTC) Subject: [DB-SIG] Re: More trouble with DCOracle2 on HPUX11I References: <78E14EC993154B4AA6D771902D2CAAAA1EA622@exchange.RADFORD.EDU> Message-ID: +ACI-Lusk, Paul D+ACI- [2002-10-18 20:59 GMT]: > We are getting the following error message when trying to install: > [snip tons of warnings from system compiler; weird error] Did you try the HOWTO I recently posted to this list? I used gcc 3.1. -- Gerhard From jacobs@penguin.theopalgroup.com Tue Oct 22 13:44:06 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Tue, 22 Oct 2002 08:44:06 -0400 (EDT) Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: <1035269252.533.199.camel@dsl-65-184-205-5.telocity.com> Message-ID: On 22 Oct 2002, Ian Bicking wrote: > [...] And my vague impression is that PyDO avoids all this trouble by > using the dictionary interface, so it doesn't have to create methods for > each column -- I specifically didn't want to do something like that, > because I don't want the database columns to be distinguishable from other > methods and attributes. Making that distinction, IMHO, is a significant > compromise of the whole point of a middle object. I agree, though in my mind there are some additional constraints. First, it is not desirable to pollute the namespace of your relational objects. The ideal would be that no "other methods or attributes" are visible in such an object. This does not imply that using a dictionary interface is a good thing, though it does simplify the design. Object-like interfaces feel more natural, more Pythonic, and justify the extra effort to use an object namespace. Second, minimizing the overhead required to retrieve a column value is an essential part of making an enterprise grade OR mapper. Plus, it is also desirable to encorce the data schema by disallowing the use of novel attributes that will not be persistent. The property and slots features from Python 2.2+ provide both safety and performance. There is an added bonus that each object will not allocate a per-instance dictionary, which makes a huge difference in the footprint and performance of applications that can hold many thousands of row instances. > MK does schema generation. SQLObject deliberately does not; schema > generation just didn't seem like a problem in need of solving to me. I > also want to make as few requirements on the schema as possible. It is a problem, though thankfully an orthogonal one. As are intelligent type-mapping, constraint-checking layers, connection management, and SQL dialect abstraction. The real trick is to implement these all in a weakly coupled component architecture, and yet have them all play nicely together. > Both MK and SQLObject currently only work with MySQL. I hope to extend > SQLObject, and I think it should be very easy (actually, I hope others > will extend it, but I'll help them :). There's really only one part of > SQLObject that need to be ported -- inserting a row, to be specific. I'm happy to help, though I suggest you take the first steps by creating a backend abstraction layer. Here are some things that such a layer would handle: 1) SQL literal representations and escaping (strings, identifiers, dates, timestamps, blobs, etc.) 2) Inner/outer join syntax 3) Query limits 4) Last-insertion-id requests 5) Large binary object interface Best regards, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From ianb@colorstudy.com Tue Oct 22 19:35:46 2002 From: ianb@colorstudy.com (Ian Bicking) Date: 22 Oct 2002 13:35:46 -0500 Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: References: Message-ID: <1035311746.20412.111.camel@dsl-65-184-205-5.telocity.com> On Tue, 2002-10-22 at 07:44, Kevin Jacobs wrote: > On 22 Oct 2002, Ian Bicking wrote: > > [...] And my vague impression is that PyDO avoids all this trouble by > > using the dictionary interface, so it doesn't have to create methods for > > each column -- I specifically didn't want to do something like that, > > because I don't want the database columns to be distinguishable from other > > methods and attributes. Making that distinction, IMHO, is a significant > > compromise of the whole point of a middle object. > > I agree, though in my mind there are some additional constraints. First, it > is not desirable to pollute the namespace of your relational objects. The > ideal would be that no "other methods or attributes" are visible in such an > object. This does not imply that using a dictionary interface is a good > thing, though it does simplify the design. Object-like interfaces feel more > natural, more Pythonic, and justify the extra effort to use an object > namespace. I don't know... I guess I feel otherwise. In a practical example, I have often put some data in the filesystem, and some in the database. For instance, I put images in the filesystem indexed to a row. But I don't see any reason calling code would need to know that, or distinguish that from data kept in the database. Similar with a lot of derivative data, or data that has a calculated default. > Second, minimizing the overhead required to retrieve a column value is an > essential part of making an enterprise grade OR mapper. Retrieving a column value should be fairly quick -- surely not as fast as custom C code, but I imagine fairly fast relative to the database access. We all know Python isn't the fastest, just usually fast enough -- I think SQLObject should be fast enough as well. > Plus, it is also > desirable to encorce the data schema by disallowing the use of novel > attributes that will not be persistent. The property and slots features > from Python 2.2+ provide both safety and performance. There is an added > bonus that each object will not allocate a per-instance dictionary, which > makes a huge difference in the footprint and performance of applications > that can hold many thousands of row instances. SQLObject objects are somewhat heavy -- there's probably a half-dozen instance variables in addition to one variable per column. I wouldn't keep thousands of them around without some serious concern about the performance. But then again, I wouldn't want to keep thousands around period. It's uncommon to use a thousand rows at once (though common to iterate through a thousand rows -- this is why we have generators). Right now SQLObject doesn't take advantage of expiration and generators, but I would like to add that. If you really do have tons of rows to deal with, all at the same time, then SQLObject probably isn't the right choice (at least for those tables). You probably want to do as much in SQL as possible in that case. Anyway, SQLObject isn't a DBAPI wrapper like SQLDict or others. It's meant to make middle objects -- it's meant to be the *basis* for objects with rich functionality. If I never expected to add my own methods, override behavior, or otherwise futz with the object, I would have used something like SQLDict or your db_row -- but in my own experience I was creating these richer objects anyway, and SQLObject grew out of that. Even though this is the first public release, I've been writing and refactoring and rewriting this code for over a year. This is something that I have found not just useful, but compellingly useful in my programming. It's like when I was programming with CGI -- I kept building mini frameworks without even trying. As far as safety and enforcing a schema -- I definitely don't agree with that. I don't want to enforce anything. It's not Pythonic, but moreover I don't think it's a good idea. If a programmer wants to do something stupid, that's their fault not mine. But if a programmer wants to do something smart that I didn't expect, and I keep them from doing that, then it's my fault. And if *I* want to do something smart and I keep myself from doing it, then I'm creating unnecessary inner conflict :) > > Both MK and SQLObject currently only work with MySQL. I hope to extend > > SQLObject, and I think it should be very easy (actually, I hope others > > will extend it, but I'll help them :). There's really only one part of > > SQLObject that need to be ported -- inserting a row, to be specific. > > I'm happy to help, though I suggest you take the first steps by creating a > backend abstraction layer. Here are some things that such a layer would > handle: Maybe you can help me here -- I'm not terribly familiar with many databases, and I don't know the degree to which they differ. > 1) SQL literal representations and escaping (strings, identifiers, dates, > timestamps, blobs, etc.) How much do these really vary? I'd like to avoid a full-fledged layer for this... right now I do checking for some of the reasonable builtin types (and DateTime), and let certain objects determine for themselves what their SQL should be. I'm otherwise agnostic on other types, like timestamps and blobs. I'd really like One True SQL Quoting Function... though some ways around that are occurring to me. > 2) Inner/outer join syntax I'm not even sure how this would relate to this wrapper -- right now the only generated select statements fetch row IDs. Selects definitely could be optimized, but even then I'm not doing anything that fetches a less-than-complete object, so I don't think joins would become involved. > 3) Query limits You mean, LIMIT on the end of a SELECT? Again, SQLObject remains agnostic -- you pass an object, it gets tacked on with the LIMIT, I pay no attention to what kind of object it is. > 4) Last-insertion-id requests This being the obvious abstraction issue (why couldn't they have standardized this? Stupid, stupid, stupid...) > 5) Large binary object interface I avoid large binary objects :) This would be something I'd feel comfortable leaving out -- I'd rather let the programmer understand how SQLObject is working, and code this on their own. This is an advantage of having extensible objects -- you can write your own SQL and do your own thing, and no one needs to be the wiser. But I don't really know what those interfaces look like -- it might be easy to implement for all I know. Ian From hazmat@objectrealms.net Wed Oct 23 11:20:20 2002 From: hazmat@objectrealms.net (hazmat) Date: Wed, 23 Oct 2002 03:20:20 -0700 Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: <1035311746.20412.111.camel@dsl-65-184-205-5.telocity.com> References: <1035311746.20412.111.camel@dsl-65-184-205-5.telocity.com> Message-ID: <200210230320.20680.hazmat@objectrealms.net> just to add a couple of additional data points. - http://sf.net/projects/modeling is a fairly complete r20 mapping system based intimately on webobjects apis, supported different databases at the db-api level. it is used in production by a consulting firm for several of their clients. - http://cvs.zope.org/Products/AdaptableStorage is a r2o mapping using the zodb as an abstraction layer, using a plugin storage that implements the mapping. its an experimental prototype at this point. shane hathaway also did a presentation on this at oscon, which is available at the oscon website. cheers, -haz From ianb@colorstudy.com Wed Oct 23 05:26:06 2002 From: ianb@colorstudy.com (Ian Bicking) Date: 22 Oct 2002 23:26:06 -0500 Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: <200210230320.20680.hazmat@objectrealms.net> References: <1035311746.20412.111.camel@dsl-65-184-205-5.telocity.com> <200210230320.20680.hazmat@objectrealms.net> Message-ID: <1035347166.20574.1261.camel@dsl-65-184-205-5.telocity.com> On Wed, 2002-10-23 at 05:20, hazmat wrote: > - http://cvs.zope.org/Products/AdaptableStorage > > is a r2o mapping using the zodb as an abstraction layer, using a plugin > storage that implements the mapping. its an experimental prototype at this > point. shane hathaway also did a presentation on this at oscon, which is > available at the oscon website. Mmm... I must admit, this does sound enticing: So far, this product has been used to literally "mount" both a Postgresql database and a filesystem directory into Zope, without using any subclasses of Zope classes. This is very different from most other products that provide alternative storage for Zope objects, including LocalFS, ZPatterns, DBObjects/SmartObjects, and CMF. These all require special classes to alter persistence details, but persisting to different kinds of databases should not require different classes. I makes me rethink schema parsing... though of course "mounting" only means something in the Zope context, and I'm not sure what the Right automatically-created interface would be outside of that. Ian From hazmat@objectrealms.net Wed Oct 23 19:08:58 2002 From: hazmat@objectrealms.net (hazmat) Date: Wed, 23 Oct 2002 11:08:58 -0700 Subject: [DB-SIG] Re: [Webware-discuss] [ANN] SQLObject 0.1 In-Reply-To: <1035347166.20574.1261.camel@dsl-65-184-205-5.telocity.com> References: <200210230320.20680.hazmat@objectrealms.net> <1035347166.20574.1261.camel@dsl-65-184-205-5.telocity.com> Message-ID: <200210231108.58869.hazmat@objectrealms.net> On Tuesday 22 October 2002 09:26 pm, Ian Bicking wrote: > On Wed, 2002-10-23 at 05:20, hazmat wrote: > > - http://cvs.zope.org/Products/AdaptableStorage > > > > is a r2o mapping using the zodb as an abstraction layer, using a plugin > > storage that implements the mapping. its an experimental prototype at > > this point. shane hathaway also did a presentation on this at oscon, > > which is available at the oscon website. > > Mmm... I must admit, this does sound enticing: > > So far, this product has been used to literally "mount" both a > Postgresql database and a filesystem directory into Zope, without > using any subclasses of Zope classes. This is very different from > most other products that provide alternative storage for Zope > objects, including LocalFS, ZPatterns, DBObjects/SmartObjects, and > CMF. These all require special classes to alter persistence > details, but persisting to different kinds of databases should not > require different classes. > > I makes me rethink schema parsing... though of course "mounting" only > means something in the Zope context, and I'm not sure what the Right > automatically-created interface would be outside of that. if this sort of thing interests you i highly recommend checking out the persistence-sig (and its archives) @ python.org, its somewhat dormant now. but one of the goals is to define a persistence interface, that different persistence implementations can be plugged into... well more or less ;-) the mounting syntax could be thought of as zope specific i guess, although it seems generic enough to me, in a general sense it means mounting a persistent object model onto a user's existing one, no different than say importing a module to mount that module into your runtime object model. off course maybe i've been playing with zope for too long. /me realizes he is way off topic cheers, -haz From VKryukov@ufg.com Fri Oct 25 18:59:17 2002 From: VKryukov@ufg.com (Krjukov Victor) Date: Fri, 25 Oct 2002 21:59:17 +0400 Subject: [DB-SIG] mx.ODBC.Windows.Connect problem Message-ID: <7CF3E427AE54FC42A26E68C5A89C1869011444F0@zeal.ufg.com> Hi. I have a following problem using Connect: import mx.ODBC.Windows C =3D mx.ODBC.Windows.Connect("driver=3D{SQL Server};server=3Dzsun;uid=3D;pwd=3D;database=3Ddbcompany") Traceback (most recent call last): File "", line 1, in ? mxODBC.InternalError: ('S1090', 0, '[Microsoft][ODBC Driver Manager] Invalid str ing or buffer length', 5950) However, the following VBA code works: Sub a() Dim cnn1 As ADODB.Connection =20 Set cnn1 =3D New ADODB.Connection cnn1.ConnectionString =3D "driver=3D{SQL Server};server=3Dzsun;uid=3D;pwd=3D;database=3Ddbcompany" cnn1.Open End Sub Any ideas? Thanks. Victor. From mal@lemburg.com Fri Oct 25 19:36:56 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 25 Oct 2002 20:36:56 +0200 Subject: [DB-SIG] mx.ODBC.Windows.Connect problem References: <7CF3E427AE54FC42A26E68C5A89C1869011444F0@zeal.ufg.com> Message-ID: <3DB98F48.8030504@lemburg.com> Krjukov Victor wrote: > Hi. > > I have a following problem using Connect: > > import mx.ODBC.Windows > C = mx.ODBC.Windows.Connect("driver={SQL > Server};server=zsun;uid=;pwd=;database=dbcompany") Try mx.ODBC.Windows.DriverConnect() > > Traceback (most recent call last): > File "", line 1, in ? > mxODBC.InternalError: ('S1090', 0, '[Microsoft][ODBC Driver Manager] > Invalid str > ing or buffer length', 5950) > > However, the following VBA code works: > > Sub a() > Dim cnn1 As ADODB.Connection > > Set cnn1 = New ADODB.Connection > cnn1.ConnectionString = "driver={SQL > Server};server=zsun;uid=;pwd=;database=dbcompany" > cnn1.Open > End Sub > > Any ideas? > > Thanks. Victor. > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From hherb@gnumed.net Sat Oct 26 06:27:32 2002 From: hherb@gnumed.net (Horst Herb) Date: Sat, 26 Oct 2002 15:27:32 +1000 Subject: gmPgObject (was Re: [DB-SIG] [ANN] SQLObject 0.1) In-Reply-To: <1035248121.12706.127.camel@dsl-65-184-205-5.telocity.com> References: <1035248121.12706.127.camel@dsl-65-184-205-5.telocity.com> Message-ID: <200210261527.32436.hherb@gnumed.net> On Tue, 22 Oct 2002 10:55, Ian Bicking wrote: > This is the first release of SQLObject (v0.1). > > SQLObject is an object-relational mapper. It's meant to make database > rows look like normal Python objects -- no dictionary access, no We are working on a similar object-relational mapper, though ours is highly specific for PostgreSQL and depending on a few of our own internal modules (managing connection pools etc). Our approach automatically follows (dereferences) rows referenced via foreign keys, and changes are committed on object deletion, change of primary key value or on manual committ. When new objects are created, the new primary key is initialized via backend, and the object is refreshed from the backend thus respecting all backend defaults/constraints - all you need to do is creating the object and attemptimg to access/modify any column and it happens automagically. It is particularly easy to use, since all table metadata is gathered and cached in the background. All fetches are "lazy" unless forced, meaning no queries are executed unless the columns are really accessed: row = pgobject(, ) row.fetch() row["some column"] = some_value row["foreign key"]["referenced table column"] = some_value However, it is not nicely written (quick hack so far), hardly any exception / error handling at all yet, no performance considerations yet, and probably still full of bugs. There is a definite problem because of the lack of nested transactions in PostgreSQL for which we haven't found a good solution yet That said, I think our concept is sound and I'd love to attract a few people working on this together for mutual benefit. Have alook at the CVS file in http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/client/python-common/gmPgObject.py?rev=HEAD&content-type=text/vnd.viewcvs-markup Horst, coordinator "The Gnumed Project" http://gnu.org/software/gnumed From djc@object-craft.com.au Mon Oct 28 11:36:20 2002 From: djc@object-craft.com.au (Dave Cole) Date: 28 Oct 2002 22:36:20 +1100 Subject: [DB-SIG] Sybase module 0.35pre2 released Message-ID: WHAT IS IT: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. NOTES: In this release the module uses callback instead of inline error handling from the Sybase CT library. This has caused quite extensive changes to the threading support inside the low level extension module. One of the nice side effects of using callback error handling is that server errors while executing stored procedures will now be reported correctly. FreeTDS support is much improved in this version. You can build for FreeTDS like this: python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY python setup.py install The module is available here: http://www.object-craft.com.au/projects/sybase/download/sybase-0.35pre2.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ CHANGES SINCE 0.35pre1: * Changed ignored server messages to (5701, 5703). Thanks to Kevin Jacobs. * Allocate a new CS_COMMAND for each command executed on a cursor. This behaves like an explicit close() on the cursor in between commands. This makes it possible to perform multiple .execute() commands on a cursor with FreeTDS. * Added array binding to cursor to gain extra performance. Set the arraysize cursor attribute before executing a command. * Made connection locking optional. Sybase.connect(..., locking = 0) * Native DateTime types now has separate str() and repr(). print used to display "'11/01/63'". ARRAY BINDING: The following is a little test program to see the performance effect of array binding in the .fetchmany() cursor method. It looks like the speed was mostly going in function calls due to locking and single row fetching. run locking array functions time (ave 10 runs) test-array l Y N 88586 1.3248 secs test-array N N 20450 0.9803 secs test-array al Y Y 9458 0.5188 secs test-array a N Y 7262 0.5002 secs - - test-array.py - - - - - - - - - - - - - - - - - - - - - - - - import sys, Sybase def array_bind(): db = Sybase.connect('SYBASE', 'sa', '', 'sybsystemprocs', locking = do_locking) c = db.cursor() c.arraysize = 32 c.execute('select text from syscomments') num_rows = 0 while 1: rows = c.fetchmany() if not rows: break num_rows += len(rows) print num_rows, 'rows' def single_bind(): db = Sybase.connect('SYBASE', 'sa', '', 'sybsystemprocs', locking = do_locking) c = db.cursor() c.execute('select text from syscomments') num_rows = 0 while 1: row = c.fetchone() if not row: break num_rows += 1 print num_rows, 'rows' def main(): if do_array: array_bind() else: single_bind() do_profile = len(sys.argv) > 1 and sys.argv[1].find('p') >= 0 do_locking = len(sys.argv) > 1 and sys.argv[1].find('l') >= 0 do_array = len(sys.argv) > 1 and sys.argv[1].find('a') >= 0 if do_profile: import profile profile.run('main()') else: main() - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- http://www.object-craft.com.au From kajiyama@grad.sccs.chukyo-u.ac.jp Mon Oct 28 12:34:01 2002 From: kajiyama@grad.sccs.chukyo-u.ac.jp (Tamito KAJIYAMA) Date: Mon, 28 Oct 2002 21:34:01 +0900 Subject: [DB-SIG] PyGreSQL pgsource object Message-ID: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> Hi, I found that the pg module in PyGreSQL (version 3.x) contains an extension object named pgsource. It seems useful, but it is not mentioned in the documentation at all. Does this means that the pgsource object should not be used in PyGreSQL applications? Thanks, -- KAJIYAMA, Tamito From gerhard.haering@opus-gmbh.net Mon Oct 28 13:50:45 2002 From: gerhard.haering@opus-gmbh.net (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Mon, 28 Oct 2002 14:50:45 +0100 Subject: [DB-SIG] PyGreSQL pgsource object In-Reply-To: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> References: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> Message-ID: <20021028135044.GA1392@HAERING> * Tamito KAJIYAMA [2002-10-28 21:34 +0900]: > Hi, > > I found that the pg module in PyGreSQL (version 3.x) contains an > extension object named pgsource. It seems useful, but it is not > mentioned in the documentation at all. Does this means that the > pgsource object should not be used in PyGreSQL applications? What's wrong with using a DB-API module like pyPgSQL or psycopg, or even PyGreSQL's pgdb module? Does pgsource offer anything that the DB-API interface doesn't, or that cannot be easily accomplished using the DB-API interface? Btw. if you want to use PyGreSQL, I'd recommend to get the latest one from the PostgreSQL folks, for example from the PostgreSQL 7.2.2 source tree. That's where it is maintained nowadays. -- Gerhard Häring OPUS GmbH München Tel.: +49 89 - 889 49 7 - 32 http://www.opus-gmbh.net/ From kajiyama@grad.sccs.chukyo-u.ac.jp Mon Oct 28 15:55:02 2002 From: kajiyama@grad.sccs.chukyo-u.ac.jp (Tamito KAJIYAMA) Date: Tue, 29 Oct 2002 00:55:02 +0900 Subject: [DB-SIG] PyGreSQL pgsource object In-Reply-To: <20021028135044.GA1392@HAERING> (message from Gerhard =?ISO-8859-1?Q?H=E4ring?= on Mon, 28 Oct 2002 14:50:45 +0100) References: <20021028135044.GA1392@HAERING> Message-ID: <200210281555.g9SFt2123275@grad.sccs.chukyo-u.ac.jp> Gerhard H=E4ring writes: | | > I found that the pg module in PyGreSQL (version 3.x) contains an | > extension object named pgsource. It seems useful, but it is not | > mentioned in the documentation at all. Does this means that the | > pgsource object should not be used in PyGreSQL applications? | | What's wrong with using a DB-API module like pyPgSQL or psycopg, or even | PyGreSQL's pgdb module? Nothing. My question is merely whether there is any technical reason why the pgsource object has not made public. The pgsource object has a set of method names that well correspond with the PostgreSQL interface in PHP. So, I thought the pgsource object would be useful when, say, porting database applications from PHP to Python. | Btw. if you want to use PyGreSQL, I'd recommend to get the latest one fro= m the | PostgreSQL folks, for example from the PostgreSQL 7.2.2 source tree. That= 's | where it is maintained nowadays. Thanks, -- KAJIYAMA, Tamito From djc@object-craft.com.au Mon Oct 28 23:48:11 2002 From: djc@object-craft.com.au (Dave Cole) Date: 29 Oct 2002 10:48:11 +1100 Subject: [DB-SIG] Sybase module 0.35pre3 released Message-ID: WHAT IS IT: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. This release corrects a mistake I made in packaging the 0.35pre2 release. http://www.object-craft.com.au/projects/sybase/ CHANGES SINCE 0.35pre2: * Fixed the MANIFEST.in file to include freetds.h and sybasect.h. -- http://www.object-craft.com.au From TRabaut@providentfunding.com Tue Oct 29 18:08:37 2002 From: TRabaut@providentfunding.com (Tom Rabaut) Date: Tue, 29 Oct 2002 10:08:37 -0800 Subject: [DB-SIG] Opening a connection for a Microsoft SQL Server Database Message-ID: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB293E@exchange.pfloans.com> I'm having trouble getting a connection with my SQL Server Database. My = webserver and script is sitting on my D drive and my database is on my C = drive, how should I be referencing the database file? Currently my code = looks something like this: connection =3D odbc.odbc('C:/Program File/..../database') The debugger is telling me that it cannot find the file. Do I need to = include the database extension? Am I referencing the C drive = incorrectly. Thanks Tom From nobody@maui.dnsvault.com Wed Oct 30 00:33:26 2002 From: nobody@maui.dnsvault.com (Nobody) Date: Tue, 29 Oct 2002 19:33:26 -0500 Subject: [DB-SIG] A larger gold balance! Message-ID: Untitled

Hello all E-Gold and EVOcash account holders!

   We here at Your Gold Chance are honest, reliable and willing to help you achieve what you want most..... A larger e-gold balance! We have developed a program to give you a smart return without the usual wait of hyip's. For speed and convenience we utilize online digital currencies. We accept E-Gold and EVOcash.

    All investments are based on a 33 week plan. We pay you 10% per week for a total of 33 weeks. You first payment starts 7 days after you invest and your capital is returned to you at the end of the 33th week.

   The minimum Investment is $25.00USD and the maximum Investment is $25,000 USD. Do not send us any amount outside these parameters otherwise your investment will be returned without profit.

If you are interested in this program visit site:

http://www.yourgoldchance.net/invest.html

All additional information you can get here:

http://www.yourgoldchance.net/

If you would like to contact us, please send us an email:

yourgoldchance@yourgoldchance.net

Our company will continue its best efforts to make good on every payments on our program without any delay.

Thanks for choosing Your Gold Chance!
Karen Andreozzi,
President
Yor Gold Chance, Inc.

From msanchez@grupoburke.com Wed Oct 30 10:22:27 2002 From: msanchez@grupoburke.com (Marcos =?ISO-8859-1?Q?S=E1nchez?= Provencio) Date: 30 Oct 2002 11:22:27 +0100 Subject: [DB-SIG] Opening a connection for a Microsoft SQL Server Database In-Reply-To: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB293E@exchange.pfloans.com> References: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB293E@exchange.pfloans.com> Message-ID: <1035973347.1366.24.camel@cynar> SQL server is not based on file accesses, but on services. You should read the manual, really. The information you should provide is the name odbc data source. To create the odbc data source, you should use the ODBC manager, which asks you for the information needed. El mar, 29-10-2002 a las 19:08, Tom Rabaut escribi=F3: > I'm having trouble getting a connection with my SQL Server Database. My w= ebserver and script is sitting on my D drive and my database is on my C dri= ve, how should I be referencing the database file? Currently my code looks = something like this: >=20 > connection =3D odbc.odbc('C:/Program File/..../database') >=20 > The debugger is telling me that it cannot find the file. Do I need to inc= lude the database extension? Am I referencing the C drive incorrectly. Than= ks Tom >=20 > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From subscriptions@gnumed.net Thu Oct 31 05:37:58 2002 From: subscriptions@gnumed.net (Horst Herb) Date: Thu, 31 Oct 2002 16:37:58 +1100 Subject: [DB-SIG] PyGreSQL pgsource object References: <200210281234.g9SCY1M22982@grad.sccs.chukyo-u.ac.jp> <20021028135044.GA1392@HAERING> Message-ID: <3DC0C1B6.404@gnumed.net> Gerhard Häring wrote: > What's wrong with using a DB-API module like pyPgSQL or psycopg, or even > PyGreSQL's pgdb module? Does pgsource offer anything that the DB-API interface > doesn't, or that cannot be easily accomplished using the DB-API interface? While there is nothing wrong with the options you mention, the DB-API is far from being a solution. Neither connection strings nor the way returned rows are typed nor the way dates are handled are managed are consistent between adapters. We ended up having to write wrappers around wrappers to just become independend between the three main Postgres DB-API "compliant" modules for that very reason, which was pointless. When trying to use the same code for MySQL as for Postgres, it was a complete fiasco. We settled for PyPgSQL because it offered the simplest installation for those using Windows, but it leaves the question why the heck the DB-API cannot be a bit more consistent and specific. Horst From TRabaut@providentfunding.com Thu Oct 31 23:28:39 2002 From: TRabaut@providentfunding.com (Tom Rabaut) Date: Thu, 31 Oct 2002 15:28:39 -0800 Subject: [DB-SIG] Dictionaries Pass By Reference? Message-ID: <4FFD1CA10E16DE43AEDA0AB7B13B7293AB2941@exchange.pfloans.com> I'm under the understanding that dictionaries are pass by reference in = python, but it doesn't seem to be working for me. I'm declaring the = dictionary in main then passing it to a function member of a module = where it is populated, but when I attempted to use it, it is still empty = in the main program.