From phd at phdru.name Sat Oct 5 14:57:09 2013 From: phd at phdru.name (Oleg Broytman) Date: Sat, 5 Oct 2013 16:57:09 +0400 Subject: [DB-SIG] SQLObject 1.5.0 Message-ID: <20131005125709.GA19336@iskra.aviel.ru> Hello! I'm pleased to announce version 1.5.0, the first stable release of branch 1.5 of SQLObject. What's new in SQLObject ======================= Features & Interface -------------------- * Helpers for class Outer were changed to lookup columns in table's declarations. * Support for Python 2.4 is declared obsolete and will be removed in the next release. Minor features -------------- * When a PostgresConnection raises an exception the instance has code/error attributes copied from psycopg2's pgcode/pgerror attributes. * Encode unicode enum values to str. * Removed setDeprecationLevel from the list of public functions. * A number of fixes for tests. Bugfixes -------- * A bug was fixed in DBConnection.close(); close() doesn't raise an UnboundLocalError if connection pool is empty. * Fixed parameters for pymssql. Documentation ------------- * GNU LGPL text was added as docs/LICENSE file. * Old FSF address was changed to the new one. Contributors for this release are Patrick Gendron, Rhubarb Sin, Neil Muller, Robert Ayrapetyan, Gert Burger and Francisco Chiotta. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: https://pypi.python.org/pypi/SQLObject/1.5.0 News and changes: http://sqlobject.org/News.html Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From tlocke at tlocke.org.uk Thu Oct 24 11:57:31 2013 From: tlocke at tlocke.org.uk (Tony Locke) Date: Thu, 24 Oct 2013 10:57:31 +0100 Subject: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 Message-ID: Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension into the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn't see anything. The reason I ask is that I'm noticing on PG8000 that the time taken to execute the warn() for each call to next() is significant for iterating over a large number of rows. I'm on the verge of suggesting getting rid of fetchmany() and just having the iterable, and making execute() return the cursor. Then instead of: cursor.execute("select * from emp") all_emps = cursor.fetchmany() you'd have: all_emps = [cursor.execute("select * from emp")] or you could do: for emp in cursor.execute("select * from emp"): pass Cheers, Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vernondcole at gmail.com Fri Oct 25 07:59:39 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Thu, 24 Oct 2013 23:59:39 -0600 Subject: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 In-Reply-To: References: Message-ID: I don't think that fetchmany() or its brothers will, or should, go away. I, for one, want api3 to be backwards compatible. I suspect, however that use of the iterator will become the prevalent pattern in the future. I am +1 on iterable cursors being required for API 3. I am starting a project just now which will be using SQLite. The present production version of adodbapi has all of the features that I (humbly) think ought to be in the v3 api. Since SQLite is the only major database that ADO does _not_ cover, I am thinking of forking it and adding the updated features I want to use. Hopefully, my fevered mind will cool before that happens. On Thu, Oct 24, 2013 at 3:57 AM, Tony Locke wrote: > Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension > into the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn't > see anything. The reason I ask is that I'm noticing on PG8000 that the time > taken to execute the warn() for each call to next() is significant for > iterating over a large number of rows. > > I'm on the verge of suggesting getting rid of fetchmany() and just having > the iterable, and making execute() return the cursor. Then instead of: > > cursor.execute("select * from emp") > all_emps = cursor.fetchmany() > > you'd have: > > all_emps = [cursor.execute("select * from emp")] > > or you could do: > > for emp in cursor.execute("select * from emp"): > pass > > > > Cheers, > > Tony. > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > https://mail.python.org/mailman/listinfo/db-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele.varrazzo at gmail.com Fri Oct 25 12:31:49 2013 From: daniele.varrazzo at gmail.com (Daniele Varrazzo) Date: Fri, 25 Oct 2013 11:31:49 +0100 Subject: [DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3 In-Reply-To: References: Message-ID: On Thu, Oct 24, 2013 at 10:57 AM, Tony Locke wrote: > Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension into > the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn't see > anything. The reason I ask is that I'm noticing on PG8000 that the time > taken to execute the warn() for each call to next() is significant for > iterating over a large number of rows. PG8000 is pretty much free to not raise the warnings, if it creates problems and you report it as a bug to its developers. Of course the warning could be also raises once with a lightweight check instead of relying on the Python machinery to suppress duplicates, if it gets in the way. I don't think the deficiencies in an adapter's implementation should be driving the standard's design. > I'm on the verge of suggesting getting rid of fetchmany() and just having > the iterable, and making execute() return the cursor. Then instead of: > > cursor.execute("select * from emp") > all_emps = cursor.fetchmany() > > you'd have: > > all_emps = [cursor.execute("select * from emp")] > > or you could do: > > for emp in cursor.execute("select * from emp"): > pass >From this example it seems you want to get rid of fetchall() instead. Fetchmany has other useful use cases. In order to enable the idiom of the example, if a cursor supports iteration, it is enough for cursor.execute() to return "self": IIRC some adapters do that, and I find it a clever idea. -- Daniele From songofacandy at gmail.com Fri Oct 25 09:27:55 2013 From: songofacandy at gmail.com (INADA Naoki) Date: Fri, 25 Oct 2013 16:27:55 +0900 Subject: [DB-SIG] asyncio support Message-ID: Does someone consider DB-API for asyncio? -- INADA Naoki -------------- next part -------------- An HTML attachment was scrubbed... URL: