From phd at phd.pp.ru Sun May 4 16:16:33 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Sun, 4 May 2008 18:16:33 +0400 Subject: [DB-SIG] SQLObject 0.9.6 Message-ID: <20080504141633.GA3097@phd.pp.ru> Hello! I'm pleased to announce version 0.9.6, a minor bug fix release of SQLObject. 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: http://cheeseshop.python.org/pypi/SQLObject/0.9.6 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.9.5 ---------------- Bug Fixes ~~~~~~~~~ * A bug in inheritable delColumn() that doesn't remove properties was fixed. * A minor bug was fixed in col.py - the registry must be passed to findClass(). * Reverted the patch declarative.threadSafeMethod() - it causes more harm then good. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From phd at phd.pp.ru Sun May 4 16:18:32 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Sun, 4 May 2008 18:18:32 +0400 Subject: [DB-SIG] SQLObject 0.10.1 Message-ID: <20080504141832.GE3097@phd.pp.ru> Hello! I'm pleased to announce version 0.10.1, a bugfix release of 0.10 branch of SQLObject. 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: http://cheeseshop.python.org/pypi/SQLObject/0.10.1 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.10.0 ----------------- Bug Fixes ~~~~~~~~~ * Fixed a bug: limit doesn't work in sqlbuilder.Select. * A bug in inheritable delColumn() that doesn't remove properties was fixed. * A minor bug was fixed in col.py - the registry must be passed to findClass(). * Reverted the patch declarative.threadSafeMethod() - it causes more harm then good. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From bkline at rksystems.com Wed May 7 22:11:34 2008 From: bkline at rksystems.com (Bob Kline) Date: Wed, 07 May 2008 16:11:34 -0400 Subject: [DB-SIG] Suggestion for alterning the spec for Cursor.nextset() Message-ID: <48220CF6.4000409@rksystems.com> [I've looked back through several months' worth of the list archives to see if this is a topic which has already been visited, but I wasn't able to find a search interface, and I wasn't really up to doing the month-at-a-time thing through several years' worth of messages. Is there such an interface?] The DB API 2.0 spec has this to say about nextset(): This method will make the cursor skip to the next available set, discarding any remaining rows from the current set. If there are no more sets, the method returns None. Otherwise, it returns a true value and subsequent calls to the fetch methods will return rows from the next result set. However, it seems that reality is more subtle than this description. In the case of a multi-query stored procedure, for example, some of the queries may return rows and some might not. If the spec forces the implementers to try and detect which is which, and skip over the queries which do not return rows, then even if it's possible to make the distinction reliably for all possible back ends, the programmer will be deprived of access to the rowcount information which would otherwise be available for the queries which modify data but do not return any rows. How about substitute language something like the following: This method will make the cursor skip to the next available set, discarding any remaining rows from the current set. If there are no more sets, the method returns None. Otherwise, it returns a true value. It is the responsibility of the programmer to know whether the current result set represents a (possibly empty) set of rows available for retrieval with subsequent calls to the fetch methods. In some cases the query generating the result (for example, an INSERT statement in a stored procedure) will not provide such a set of rows, but may instead set the rowcount attribute to reflect the number of rows affected by the query. In such a case an exception will be raised if an attempt is made to fetch rows from the non-existent set of rows. The wording could probably be improved, and it's unfortunate that use of the words "set" and "sets" here covers such vague territory, but that's how things work in at least some of the underlying layers (ODBC, ADODB, SQL Server, etc.): they're apparently using "results set" to cover both a set of results which consists of a sequence of rows, as well as the results of a query for which you get information about the effects of the query instead of a retrievable set of rows. Has this been discussed before? -- Bob Kline http://www.rksystems.com mailto:bkline at rksystems.com From mal at egenix.com Wed May 7 22:47:02 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 07 May 2008 22:47:02 +0200 Subject: [DB-SIG] Suggestion for alterning the spec for Cursor.nextset() In-Reply-To: <48220CF6.4000409@rksystems.com> References: <48220CF6.4000409@rksystems.com> Message-ID: <48221546.6070803@egenix.com> On 2008-05-07 22:11, Bob Kline wrote: > [I've looked back through several months' worth of the list archives to > see if this is a topic which has already been visited, but I wasn't able > to find a search interface, and I wasn't really up to doing the > month-at-a-time thing through several years' worth of messages. Is > there such an interface?] http://www.python.org/search/ It would also be possible to build a customized search for just searching the db-sig archives and put it on the SIG page, but I don't have access to that page. > The DB API 2.0 spec has this to say about nextset(): > > This method will make the cursor skip to the next available set, > discarding any remaining rows from the current set. > > If there are no more sets, the method returns None. Otherwise, it > returns a true value and subsequent calls to the fetch methods will > return rows from the next result set. > > > However, it seems that reality is more subtle than this description. In > the case of a multi-query stored procedure, for example, some of the > queries may return rows and some might not. If the spec forces the > implementers to try and detect which is which, and skip over the queries > which do not return rows, then even if it's possible to make the > distinction reliably for all possible back ends, the programmer will be > deprived of access to the rowcount information which would otherwise be > available for the queries which modify data but do not return any rows. > How about substitute language something like the following: > > This method will make the cursor skip to the next available set, > discarding any remaining rows from the current set. > > If there are no more sets, the method returns None. Otherwise, it > returns a true value. It is the responsibility of the programmer to > know whether the current result set represents a (possibly empty) > set of rows available for retrieval with subsequent calls to the > fetch methods. In some cases the query generating the result (for > example, an INSERT statement in a stored procedure) will not provide > such a set of rows, but may instead set the rowcount attribute to > reflect the number of rows affected by the query. In such a case an > exception will be raised if an attempt is made to fetch rows from > the non-existent set of rows. > > > The wording could probably be improved, and it's unfortunate that use of > the words "set" and "sets" here covers such vague territory, but that's > how things work in at least some of the underlying layers (ODBC, ADODB, > SQL Server, etc.): they're apparently using "results set" to cover both > a set of results which consists of a sequence of rows, as well as the > results of a query for which you get information about the effects of > the query instead of a retrievable set of rows. > > Has this been discussed before? I'm not sure, but agree that things are a bit more subtle than the short snippet in the API spec. There's also the problem of differentiating between an empty result set and one that doesn't have any output columns, e.g. .fetchall() will (usually) return [] for the first and raise an exception for the second. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 07 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From phd at phd.pp.ru Fri May 30 15:10:48 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Fri, 30 May 2008 17:10:48 +0400 Subject: [DB-SIG] SQLObject 0.9.7 Message-ID: <20080530131048.GF32657@phd.pp.ru> Hello! I'm pleased to announce version 0.9.7, a minor bug fix release of SQLObject. 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: http://cheeseshop.python.org/pypi/SQLObject/0.9.7 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.9.6 ---------------- Small Features ~~~~~~~~~~~~~~ * Use VARCHAR(MAX) and VARBINARY(MAX) for MSSQL >= 9.0. * Run post_funcs after RowDestroySignal. Bug Fixes ~~~~~~~~~ * Fixed a minor bug in Set column. * A bug fixed for RowCreatedSignal together with InheritableSQLObject: run post_funcs after the entire hierarchy has been created. * Aggregate functions now honors 'distinct'. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From phd at phd.pp.ru Fri May 30 15:12:34 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Fri, 30 May 2008 17:12:34 +0400 Subject: [DB-SIG] SQLObject 0.10.2 Message-ID: <20080530131234.GJ32657@phd.pp.ru> Hello! I'm pleased to announce version 0.10.2, a bugfix release of 0.10 branch of SQLObject. 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: http://cheeseshop.python.org/pypi/SQLObject/0.10.2 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.10.1 ----------------- Small Features ~~~~~~~~~~~~~~ * Use VARCHAR(MAX) and VARBINARY(MAX) for MSSQL >= 9.0. * Run post_funcs after RowDestroySignal. Bug Fixes ~~~~~~~~~ * Fixed a minor bug in Set column. * A bug fixed for RowCreatedSignal together with InheritableSQLObject: run post_funcs after the entire hierarchy has been created. * Aggregate functions now honors 'distinct'. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN.