sqlobject-cvs — CVS notification

[SQL-CVS] r1919 - home/phd/SQLObject/paramstyles

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:57:56 -0600 (Fri, 08 Sep 2006)
New Revision: 1919

Modified:
   home/phd/SQLObject/paramstyles/setup.py
Log:
Merged patches from the revisions 1916:1918 from the trunk

Modified: home/phd/SQLObject/paramstyles/setup.py
===================================================================
--- home/phd/SQLObject/paramstyles/setup.py	2006-09-08 18:56:48 UTC (rev 1918)
+++ home/phd/SQLObject/paramstyles/setup.py	2006-09-08 18:57:56 UTC (rev 1919)
@@ -83,9 +83,13 @@
 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 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, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and
+Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also
+known as SAPDB).
 
 
 Where is SQLObject
@@ -101,7 +105,7 @@
 http://news.gmane.org/gmane.comp.python.sqlobject
 
 Download:
-http://prdownloads.sourceforge.net/sqlobject/SQLObject-@@.tar.gz?download
+http://cheeseshop.python.org/pypi/SQLObject/
 
 News and changes:
 http://sqlobject.org/docs/News.html
@@ -112,7 +116,8 @@
 
 @@ CHANGES
 
-For a more complete list, please see the news: http://sqlobject.org/docs/News.html
+For a more complete list, please see the news:
+http://sqlobject.org/docs/News.html
 
 -- 
 Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

[SQL-CVS] r1918 - SQLObject/branches/0.7-bugfix

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:56:48 -0600 (Fri, 08 Sep 2006)
New Revision: 1918

Modified:
   SQLObject/branches/0.7-bugfix/setup.py
Log:
Changed the download link.


Modified: SQLObject/branches/0.7-bugfix/setup.py
===================================================================
--- SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 18:55:41 UTC (rev 1917)
+++ SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 18:56:48 UTC (rev 1918)
@@ -78,9 +78,13 @@
 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 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, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and
+Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also
+known as SAPDB).
 
 
 Where is SQLObject
@@ -96,7 +100,7 @@
 http://news.gmane.org/gmane.comp.python.sqlobject
 
 Download:
-http://prdownloads.sourceforge.net/sqlobject/SQLObject-@@.tar.gz?download
+http://cheeseshop.python.org/pypi/SQLObject/
 
 News and changes:
 http://sqlobject.org/docs/News.html
@@ -107,7 +111,8 @@
 
 @@ CHANGES
 
-For a more complete list, please see the news: http://sqlobject.org/docs/News.html
+For a more complete list, please see the news:
+http://sqlobject.org/docs/News.html
 
 -- 
 Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

[SQL-CVS] r1917 - SQLObject/trunk

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:55:41 -0600 (Fri, 08 Sep 2006)
New Revision: 1917

Modified:
   SQLObject/trunk/setup.py
Log:
Changed the download link.


Modified: SQLObject/trunk/setup.py
===================================================================
--- SQLObject/trunk/setup.py	2006-09-08 18:50:07 UTC (rev 1916)
+++ SQLObject/trunk/setup.py	2006-09-08 18:55:41 UTC (rev 1917)
@@ -83,9 +83,13 @@
 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 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, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and
+Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also
+known as SAPDB).
 
 
 Where is SQLObject
@@ -101,7 +105,7 @@
 http://news.gmane.org/gmane.comp.python.sqlobject
 
 Download:
-http://prdownloads.sourceforge.net/sqlobject/SQLObject-@@.tar.gz?download
+http://cheeseshop.python.org/pypi/SQLObject/
 
 News and changes:
 http://sqlobject.org/docs/News.html
@@ -112,7 +116,8 @@
 
 @@ CHANGES
 
-For a more complete list, please see the news: http://sqlobject.org/docs/News.html
+For a more complete list, please see the news:
+http://sqlobject.org/docs/News.html
 
 -- 
 Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

[SQL-CVS] r1916 - home/phd/SQLObject/paramstyles

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:50:07 -0600 (Fri, 08 Sep 2006)
New Revision: 1916

Modified:
   home/phd/SQLObject/paramstyles/setup.py
Log:
Merged patches from the revisions 1913:1915 from the trunk

Modified: home/phd/SQLObject/paramstyles/setup.py
===================================================================
--- home/phd/SQLObject/paramstyles/setup.py	2006-09-08 18:49:19 UTC (rev 1915)
+++ home/phd/SQLObject/paramstyles/setup.py	2006-09-08 18:50:07 UTC (rev 1916)
@@ -85,7 +85,7 @@
 
 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, and Firebird.  It also has newly added support for Sybase and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
 
 
 Where is SQLObject

[SQL-CVS] r1915 - SQLObject/branches/0.7-bugfix

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:49:19 -0600 (Fri, 08 Sep 2006)
New Revision: 1915

Modified:
   SQLObject/branches/0.7-bugfix/setup.py
Log:
Mention MSSQL in the template.


Modified: SQLObject/branches/0.7-bugfix/setup.py
===================================================================
--- SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 18:48:57 UTC (rev 1914)
+++ SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 18:49:19 UTC (rev 1915)
@@ -80,7 +80,7 @@
 
 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, and Firebird.  It also has newly added support for Sybase and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
 
 
 Where is SQLObject

[SQL-CVS] r1914 - SQLObject/trunk

[<sub...@co...>]

Author: phd
Date: 2006-09-08 12:48:57 -0600 (Fri, 08 Sep 2006)
New Revision: 1914

Modified:
   SQLObject/trunk/setup.py
Log:
Mention MSSQL in the template.


Modified: SQLObject/trunk/setup.py
===================================================================
--- SQLObject/trunk/setup.py	2006-09-08 16:08:43 UTC (rev 1913)
+++ SQLObject/trunk/setup.py	2006-09-08 18:48:57 UTC (rev 1914)
@@ -85,7 +85,7 @@
 
 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, and Firebird.  It also has newly added support for Sybase and MaxDB (also known as SAPDB).
+SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird.  It also has newly added support for Sybase, MSSQL and MaxDB (also known as SAPDB).
 
 
 Where is SQLObject

[SQL-CVS] r1913 - SQLObject/branches/0.7-bugfix

[<sub...@co...>]

Author: ianb
Date: 2006-09-08 10:08:43 -0600 (Fri, 08 Sep 2006)
New Revision: 1913

Modified:
   SQLObject/branches/0.7-bugfix/setup.py
Log:
updated setup.py description

Modified: SQLObject/branches/0.7-bugfix/setup.py
===================================================================
--- SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 16:05:13 UTC (rev 1912)
+++ SQLObject/branches/0.7-bugfix/setup.py	2006-09-08 16:08:43 UTC (rev 1913)
@@ -33,8 +33,13 @@
 Supports MySQL, PostgreSQL, SQLite, Firebird, Sybase, and MaxDB
 (SAPDB).
 
-For development see the `subversion repository
-<http://svn.colorstudy.com/SQLObject/trunk#egg=SQLObject-0.8dev>`_
+The trunk is available in a `Subversion repository
+<http://svn.sqlobject.org/SQLObject/trunk#egg=SQLObject-dev>`_ installable with
+``easy_install SQLObject==dev``
+
+The 0.7 bugfix branch is `also available
+<http://svn.sqlobject.org/SQLObject/branches/0.7-bugfix#egg=SQLObject-bugfix>`_
+installable with ``easy_install SQLObject==bugfix``.
 """,
       classifiers=[
         "Development Status :: 5 - Production/Stable",

[SQL-CVS] r1912 - SQLObject/tags/0.7.1rc1

[<sub...@co...>]

Author: ianb
Date: 2006-09-08 10:05:13 -0600 (Fri, 08 Sep 2006)
New Revision: 1912

Modified:
   SQLObject/tags/0.7.1rc1/setup.cfg
   SQLObject/tags/0.7.1rc1/setup.py
Log:
description and version updates

Modified: SQLObject/tags/0.7.1rc1/setup.cfg
===================================================================
--- SQLObject/tags/0.7.1rc1/setup.cfg	2006-09-08 16:01:19 UTC (rev 1911)
+++ SQLObject/tags/0.7.1rc1/setup.cfg	2006-09-08 16:05:13 UTC (rev 1912)
@@ -1,7 +1,3 @@
-[egg_info]
-tag_build = dev
-tag_svn_revision = true
-
 [pudge]
 title = SQLObject
 dest = docs/html

Modified: SQLObject/tags/0.7.1rc1/setup.py
===================================================================
--- SQLObject/tags/0.7.1rc1/setup.py	2006-09-08 16:01:19 UTC (rev 1911)
+++ SQLObject/tags/0.7.1rc1/setup.py	2006-09-08 16:05:13 UTC (rev 1912)
@@ -19,7 +19,7 @@
     DistributionMetadata.download_url = None
 
 setup(name="SQLObject",
-      version="0.7.1",
+      version="0.7.1rc1",
       description="Object-Relational Manager, aka database wrapper",
       long_description="""\
 SQLObject is a popular *Object Relational Manager* for providing an
@@ -33,8 +33,13 @@
 Supports MySQL, PostgreSQL, SQLite, Firebird, Sybase, and MaxDB
 (SAPDB).
 
-For development see the `subversion repository
-<http://svn.colorstudy.com/SQLObject/trunk#egg=SQLObject-0.8dev>`_
+The trunk is available in a `Subversion repository
+<http://svn.sqlobject.org/SQLObject/trunk#egg=SQLObject-dev>`_ installable with
+``easy_install SQLObject==dev``
+
+The 0.7 bugfix branch is `also available
+<http://svn.sqlobject.org/SQLObject/branches/0.7-bugfix#egg=SQLObject-bugfix>`_
+installable with ``easy_install SQLObject==bugfix``.
 """,
       classifiers=[
         "Development Status :: 5 - Production/Stable",

[SQL-CVS] r1911 - SQLObject/tags

[<sub...@co...>]

Author: ianb
Date: 2006-09-08 10:01:19 -0600 (Fri, 08 Sep 2006)
New Revision: 1911

Added:
   SQLObject/tags/0.7.1rc1/
Log:
Tag for release

Copied: SQLObject/tags/0.7.1rc1 (from rev 1910, SQLObject/branches/0.7-bugfix)

[SQL-CVS] [ sqlobject-Bugs-1496014 ] None in enumValues fails

[SourceForge.net <no...@so...>]

Bugs item #1496014, was opened at 2006-05-27 16:42
Message generated for change (Comment added) made by nitwit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MySQL
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Muller (nitwit)
Assigned to: Nobody/Anonymous (nobody)
Summary: None in enumValues fails

Initial Comment:
SQLObject-0.7.1b1

MySQL does not allow NULL inside the ENUM statemnt, so
the construction
EnumCol(enumValues=['a','b',None],default=None) will fail.

Since this construction works fine with sqlite and
postgresql, this is an issue. The attached patch fixes
the problem here.



----------------------------------------------------------------------

>Comment By: Neil Muller (nitwit)
Date: 2006-09-07 18:44

Message:
Logged In: YES 
user_id=698097

I've already conceded that the earlier proposed patch was
incorrect, so that currently won't happen.

With the mysql_enum patch I'm currently proposing, the
result for databases other than MySQL shouldn't change from
what currently happens. The mysql_enum patch aims to map the
the present of None in the EnumCol to a NULL constraint on
the column as this seems, based on the MySQL documentation,
the only way of specifying wether NULL's are accepted or not
for ENUM's. 

The obvious alternative is to disallow None's in EnumCol's
when using MySQL entirely, but that seems to be the sort of
database specific behaviour SQLObject should be hiding from
the user.

The proposed enum_doc_patch tries to describe the potential
pitfall of using the EnumCols('a','b',None) construction
with postgresql, but doesn't change the behaviour at all.
I'd be happy to add a warning to the code as well if that
would be preffered. I've left the other databases alone
since I can't readily test them.


----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 17:49

Message:
Logged In: YES 
user_id=4799

But what if a user wrtes

EnumCol(enumValues=['a','b',None],default=None)

and got

create table t (c1 varchar(2) check (c1 in
('a','b')));

??? Wouldn't it surpize him/her? Wouldn't it be better to
raise an error instead of silently hiding it?

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-09-05 23:33

Message:
Logged In: YES 
user_id=698097

The second issue only applies if a postgresql database is
being accessed without using sqlobject as well.

he check constraint approach used doesn't work as expected
for postgresql. 
  EnumCol(enumValues=['a','b',None],default=None) 
produces something like:
  create table t (c1 varchar(2) check (c1 in ('a','b',NULL)));
However: 
   insert into t values ('1');
will succeed, because of how postgresql interprets
conditions involving NULL, as discussed in the message I
linked to. Similiar issues may arise with other databases.

However, since the call succeeds, a documentation note is
probably adequate. I've attached a possible patch to
SQLObject.txt as enum_doc_patch, although this probably
needs furtehr work.



----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-09-05 23:16

Message:
Logged In: YES 
user_id=698097

I've unfortunately combined two issues here, and I'll agree
that the second patch is incorrect.

There is an actual bug here. The current sqlobject logic
breaks on mysql:
   The construction:
 EnumCol(enumValues=['a','b',None],default=None) 
  maps to 
 CREATE TABLE t (c1 ENUM ('a','b',NULL)); 
which is not valid for MySQL, which wants NULL's for ENUM
columns handled as NULL constraints. This makes using None
in the EnumCol impossible for MySQL. The mysql_enum patch
attached aims to create a suitable constraint if None is
present EnumCol.


----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-05 15:57

Message:
Logged In: YES 
user_id=4799

This contradicts to Python philoshy "We all are grown-ups
people". If you know None (NULL) in enums is such a bad idea
- just dont use it. But forcibly remove it when the user
clearly states "I want my Nones here" is too much. Instead
of such removing write a documentation patch and clearly
explain the caveats.

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-05-29 22:39

Message:
Logged In: YES 
user_id=698097

I was pointed at
http://archives.postgresql.org/pgsql-sql/2004-12/msg00065.php,
which illustrates that NULL in the check constraint approach
used to implement EnumCol for postges and other databases
behave in an unexpected way due to the three state logic SQL
uses. Thus a believe this second patch, which excludes Nones
from all the database backends should be prefferred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1463974 ] Column name collides with internal method

[SourceForge.net <no...@so...>]

Bugs item #1463974, was opened at 2006-04-04 12:20
Message generated for change (Comment added) made by ptrck
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: SQLObject release (specify)
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Patrick Coleman (ptrck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Column name collides with internal method

Initial Comment:
Hi,

My database has a column 'expire' in a certain table.
It appears that when SQLObject calls expire() (line
778, dbconnection.py) on a cache object from that
table, rather than calling the expire method to expire
the object from cache it actually returns the value
from the 'expire' column, which being a Long of course
isn't callable, resulting in the attached exception.

I propose that internal methods used by SQLObject use
names that are unlikely to collide with column names
(perhaps by prepending __SQLObject__ or similar), and
that these internal names be documented so database
designers can avoid using names that may collide.

SQLObject is SQLObject-0.7.0-py2.4, as shipped with
Turbogears 0.8a3-py2.4.

Thanks,
Patrick
--
http://www.labyrinthdata.net.au

----------------------------------------------------------------------

>Comment By: Patrick Coleman (ptrck)
Date: 2006-09-08 00:03

Message:
Logged In: YES 
user_id=646977

Thanks for the suggestion - I'll give it a try. 

However the problem, as I'm sure you realise, is *not* that
the column 'expire' in my database is inaccessible. The
problem is that *all transaction support* in SQLObject
completely breaks when a column called 'expire' exists
anywhere in the database. 

Specifically, rollbacks don't work at all which more or less
defeats the point of transactions.

The result for end users is that when they install SQLObject
on an existing database with a column called 'expire',
SQLObject breaks inexplicably. There is no documentation of
this behaviour, and so most people are just going to
conclude that SQLObject is broken, rather than performing
this workaround.

I agree that expire is a public method, but I feel that
perhaps the current behavior should be modified so that:

 - SQLObject noticies a column the same name as a public
method and throws a meaningful error; or
 - SQLObject noticies a column the same name as a public
method and overrides the public method with the column
method (but internally continues to use the non-column
public method, so that eg. transactions do not break as they
do now); or
 - SQLObject notices a column the same name as a public
method and refuses to publish the column method.

--Patrick

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 23:43

Message:
Logged In: YES 
user_id=4799

But .expire is not an internal method - it is perfectly
valid public method. Now think you read or write
inst.__SQLObject__expire() in some code instead of
inst.expire()!

The workaround would be to made the column's name and db
anme different:

local_expire = DateTimeCol(dbName="expire")

Now you can access inst.local_expire (or whatever you name
it) and call inst.expire().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1496014 ] None in enumValues fails

[SourceForge.net <no...@so...>]

Bugs item #1496014, was opened at 2006-05-27 18:42
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MySQL
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Muller (nitwit)
Assigned to: Nobody/Anonymous (nobody)
Summary: None in enumValues fails

Initial Comment:
SQLObject-0.7.1b1

MySQL does not allow NULL inside the ENUM statemnt, so
the construction
EnumCol(enumValues=['a','b',None],default=None) will fail.

Since this construction works fine with sqlite and
postgresql, this is an issue. The attached patch fixes
the problem here.



----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:49

Message:
Logged In: YES 
user_id=4799

But what if a user wrtes

EnumCol(enumValues=['a','b',None],default=None)

and got

create table t (c1 varchar(2) check (c1 in
('a','b')));

??? Wouldn't it surpize him/her? Wouldn't it be better to
raise an error instead of silently hiding it?

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-09-06 01:33

Message:
Logged In: YES 
user_id=698097

The second issue only applies if a postgresql database is
being accessed without using sqlobject as well.

he check constraint approach used doesn't work as expected
for postgresql. 
  EnumCol(enumValues=['a','b',None],default=None) 
produces something like:
  create table t (c1 varchar(2) check (c1 in ('a','b',NULL)));
However: 
   insert into t values ('1');
will succeed, because of how postgresql interprets
conditions involving NULL, as discussed in the message I
linked to. Similiar issues may arise with other databases.

However, since the call succeeds, a documentation note is
probably adequate. I've attached a possible patch to
SQLObject.txt as enum_doc_patch, although this probably
needs furtehr work.



----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-09-06 01:16

Message:
Logged In: YES 
user_id=698097

I've unfortunately combined two issues here, and I'll agree
that the second patch is incorrect.

There is an actual bug here. The current sqlobject logic
breaks on mysql:
   The construction:
 EnumCol(enumValues=['a','b',None],default=None) 
  maps to 
 CREATE TABLE t (c1 ENUM ('a','b',NULL)); 
which is not valid for MySQL, which wants NULL's for ENUM
columns handled as NULL constraints. This makes using None
in the EnumCol impossible for MySQL. The mysql_enum patch
attached aims to create a suitable constraint if None is
present EnumCol.


----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-05 17:57

Message:
Logged In: YES 
user_id=4799

This contradicts to Python philoshy "We all are grown-ups
people". If you know None (NULL) in enums is such a bad idea
- just dont use it. But forcibly remove it when the user
clearly states "I want my Nones here" is too much. Instead
of such removing write a documentation patch and clearly
explain the caveats.

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-05-30 00:39

Message:
Logged In: YES 
user_id=698097

I was pointed at
http://archives.postgresql.org/pgsql-sql/2004-12/msg00065.php,
which illustrates that NULL in the check constraint approach
used to implement EnumCol for postges and other databases
behave in an unexpected way due to the three state logic SQL
uses. Thus a believe this second patch, which excludes Nones
from all the database backends should be prefferred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1522366 ] No intermidiate table crated with one way RelatedJoin

[SourceForge.net <no...@so...>]

Bugs item #1522366, was opened at 2006-07-14 11:34
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1522366&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: SQLObject release (specify)
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: No intermidiate table crated with one way RelatedJoin

Initial Comment:
I'm using SQLObject-0.7.1dev_r1675-py2.4.egg with
Turbogears 0.9a6

When running tg-admin sql (sql|create) I get notice the
following misfeature:

RelatedJoin intermediate tables are only created when
the table with the "lowest sorted" name is processed
even if only the "highest sorted" name has a RelatedJoin.

class File(SQLObject):
    filename = UnicodeCol()
    fileType = StringCol()
    sha1HexDigest = StringCol(length=40, alternateID=True)
    # NO related join here!

class Project(SQLObject, HelperClassNotSqlObject):
    class sqlmeta:
        # Force SQLObject to create the intermediate
        # project_dumb_file table when looking at our
project
        # files RelationalJoin instead of waiting to 
        # create it until it finds the projects
RelationalJoin
        # in DumbFile (which dows not exist). Our table
must
        # be lexiographically smaller than DumbFile
        # a < d   ->  aproject < dumb_file
        table = "aproject"
        _defaultOrder = 'projectNumber'
        
    projectNumber = StringCol()
    files = RelatedJoin("File")
    description = UnicodeCol(default="")

I do not want a relation from file to project because
many classes has files and I do not want File to have
relations to all these classes when looking at classes
related to a file is not needed but looking at files
related to a project is wery much needed.


----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:47

Message:
Logged In: YES 
user_id=4799

Then don't do that. Create a proper RelatedJoin in the other
direction.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-07-14 11:44

Message:
Logged In: NO 

Okay, it seems I was optimistic when renaming only the
table. Actually the class has to be renamed, but this breaks
with the following error:

Traceback (most recent call last):
  File "c:\Python24\Scripts\tg-admin-script.py", line 7, in ?
    sys.exit(
  File
"c:\python24\lib\site-packages\TurboGears-0.9a6-py2.4.egg\turbogears\command\base.py",
line 275, in main
    command.run()
  File
"c:\python24\lib\site-packages\TurboGears-0.9a6-py2.4.egg\turbogears\command\base.py",
line 134, in run
    command.the_runner.run(sys.argv)
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\manager\command.py",
line 102, in run
    runner.run()
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\manager\command.py",
line 233, in run
    self.command()
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\manager\command.py",
line 508, in command
    print cls.createTableSQL().strip() + ';\n'
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\main.py",
line 1336, in createTableSQL
    sql += '\n' + cls.createJoinTablesSQL(connection=conn)
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\main.py",
line 1357, in createJoinTablesSQL
    for join in cls._getJoinsToCreate():
  File
"c:\python24\lib\site-packages\SQLObject-0.7.1dev_r1675-py2.4.egg\sqlobject\main.py",
line 1390, in _getJoinsToCreate
    if join.soClass.__name__ > join.otherClass.__name__:
AttributeError: 'SORelatedJoin' object has no attribute
'otherClass'


And, I have no intention of renaming Project to aProject
anyway ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1522366&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1473819 ] SQLObject does not quote table/column names

[SourceForge.net <no...@so...>]

Bugs item #1473819, was opened at 2006-04-21 00:44
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1473819&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SQLObject does not quote table/column names

Initial Comment:
SQLObject should properly escape table and column names
to allow people to use reserved keywords as tables and
columns.

An example:

Bad: select order from group;
Good: select `order` from `group`;
Good: select `anything` from `whatever` where
`something`="foo"

My E-mail: ro...@di...

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:44

Message:
Logged In: YES 
user_id=4799

Backticks are only used in MySQL. Other DBMSes use other -
and all different - rules.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1473819&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1463974 ] Column name collides with internal method

[SourceForge.net <no...@so...>]

Bugs item #1463974, was opened at 2006-04-04 08:20
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: SQLObject release (specify)
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Patrick Coleman (ptrck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Column name collides with internal method

Initial Comment:
Hi,

My database has a column 'expire' in a certain table.
It appears that when SQLObject calls expire() (line
778, dbconnection.py) on a cache object from that
table, rather than calling the expire method to expire
the object from cache it actually returns the value
from the 'expire' column, which being a Long of course
isn't callable, resulting in the attached exception.

I propose that internal methods used by SQLObject use
names that are unlikely to collide with column names
(perhaps by prepending __SQLObject__ or similar), and
that these internal names be documented so database
designers can avoid using names that may collide.

SQLObject is SQLObject-0.7.0-py2.4, as shipped with
Turbogears 0.8a3-py2.4.

Thanks,
Patrick
--
http://www.labyrinthdata.net.au

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:43

Message:
Logged In: YES 
user_id=4799

But .expire is not an internal method - it is perfectly
valid public method. Now think you read or write
inst.__SQLObject__expire() in some code instead of
inst.expire()!

The workaround would be to made the column's name and db
anme different:

local_expire = DateTimeCol(dbName="expire")

Now you can access inst.local_expire (or whatever you name
it) and call inst.expire().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1463974&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1392862 ] An SQLObject class can't natively refer to another class in

[SourceForge.net <no...@so...>]

Bugs item #1392862, was opened at 2005-12-29 17:09
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1392862&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: SQLObject release (specify)
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: An SQLObject class can't natively refer to another class in 

Initial Comment:
Submitted by: michele.cella AT gmail DOT com

SQLObject 0.8

This was (is) needed by the TurboGears identity system.

The only (ugly) solution is to use names like TG_User.

Related links:

http://groups.google.com/group/turbogears/browse_frm/thread/a9aa7fe3f4e346ef/a782f8a010bcdbde?q=jeff+registry&rnum=1#a782f8a010bcdbde

http://nerd.newburyportion.com/2005/11/updated-identity-framework

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:35

Message:
Logged In: YES 
user_id=4799

That's exactly what registries are - to separate tables
from, e.g. different databases.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-12-29 17:11

Message:
Logged In: NO 

Right subject was:

An SQLObject class can't natively refer to another class in
a separate registry

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1392862&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1243224 ] crash using a UnicodeCol defined as alternateID.

[SourceForge.net <no...@so...>]

Bugs item #1243224, was opened at 2005-07-22 21:23
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1243224&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General
Group: SQLObject release (specify)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Oleg Broytmann (phd)
Summary: crash using a UnicodeCol defined as alternateID.

Initial Comment:
Using SQLObject 0.6.1 with sqlite-3.2.2 and pysqlite-2.0.3.

I have a table with a UnicodeCol defined as alternateID.
sqlobject crashes when using a unicode string.

Example:
===========================================
# -*- coding: iso8859-1 -*-

from sqlobject import SQLiteConnection, SQLObject,
UnicodeCol
from sqlobject.sqlite import builder

SQLiteConnection = builder()
conn = SQLiteConnection('test.db')

class MyTable(SQLObject):
    _connection = conn
    name = UnicodeCol(alternateID=True)

MyTable.createTable(ifNotExists=True)
row1 = MyTable(name = 'Tom')
row2 = MyTable(name = u'I')

del(row1)
del(row2)

print MyTable.byName('Tom')
print MyTable.byName(u'I')
===========================================

[inigo@inigo ~]$ python test.py
Traceback (most recent call last):
  File "test.py", line 14, in ?
    row1 = MyTable(name = 'Tom')
  File
"/usr/lib/python2.4/site-packages/sqlobject/main.py",
line 890, in __init__
    self._create(id, **kw)
  File
"/usr/lib/python2.4/site-packages/sqlobject/main.py",
line 923, in _create
    self._SO_finishCreate(id)
  File
"/usr/lib/python2.4/site-packages/sqlobject/main.py",
line 947, in _SO_finishCreate
    id, names, values)
  File
"/usr/lib/python2.4/site-packages/sqlobject/dbconnection.py",
line 241, in queryInsertID
    return self._runWithConnection(self._queryInsertID,
soInstance, id, names, values)
  File
"/usr/lib/python2.4/site-packages/sqlobject/dbconnection.py",
line 125, in _runWithConnection
    val = meth(conn, *args)
  File
"/usr/lib/python2.4/site-packages/sqlobject/sqlite/sqliteconnection.py",
line 47, in _queryInsertID
    c.execute(q)
  File
"/usr/src/build/539311-i386/install//usr/lib/python2.4/site-packages/sqlite/main.py",
line 244, in execute
    _sqlite.IntegrityError: column name is not unique
[inigo@inigo ~]$


----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-09-07 19:33

Message:
Logged In: YES 
user_id=4799

That's been mostly fixed.

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2005-09-13 17:21

Message:
Logged In: YES 
user_id=4799

And the second problem is that .byName() requires strings,
so you have to convert unicode to dbEncoding manually. This
works:

print MyTable.byName(u'IЯigo'.encode("UTF-8"))

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2005-07-25 09:02

Message:
Logged In: YES 
user_id=4799

SQLObject is not yet fully compatible with PySQLite2. Use
PySQLite1 instead. This works for me with PySQLite 1.1.6 and
the latest SQLObject:

# -*- coding: koi8-r -*-

from sqlobject import SQLiteConnection, SQLObject, UnicodeCol

conn = "sqlite:/:memory:?debug=1"

class MyTable(SQLObject):
    _connection = conn
    name = UnicodeCol(dbEncoding="koi8-r", alternateID=True)

MyTable.createTable(ifNotExists=True)
row1 = MyTable(name = 'Tom')
row2 = MyTable(name = u'Олег')

del(row1)
del(row2)

print MyTable.byName('Tom')
print MyTable.byName(u'Олег')

It prints:

 1/QueryOne:  SELECT tbl_name FROM sqlite_master WHERE
type='table' AND tbl_name = 'my_table'
 1/COMMIT  :  auto
 1/Query   :  CREATE TABLE my_table (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL UNIQUE
)
 1/COMMIT  :  auto
 1/QueryIns:  INSERT INTO my_table (name) VALUES ('Tom')
 1/COMMIT  :  auto
 1/QueryOne:  SELECT name FROM my_table WHERE id = 1
 1/COMMIT  :  auto
 1/QueryIns:  INSERT INTO my_table (name) VALUES ('Олег')
 1/COMMIT  :  auto
 1/QueryOne:  SELECT name FROM my_table WHERE id = 2
 1/COMMIT  :  auto
 1/QueryOne:  SELECT id, name FROM my_table WHERE name = 'Tom'
 1/COMMIT  :  auto
<MyTable 1 name=u'Tom'>
 1/QueryOne:  SELECT id, name FROM my_table WHERE name = '&#1054;&#1083;&#1077;&#1075;'
 1/COMMIT  :  auto
<MyTable 2 name=u'\u041e\u043b\u0435\u0433'>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1243224&group_id=74338

[SQL-CVS] r1910 - home/phd/SQLObject/paramstyles/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-06 08:49:00 -0600 (Wed, 06 Sep 2006)
New Revision: 1910

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/main.py
Log:
Merged patches from the revisions 1907:1909 from the trunk

Modified: home/phd/SQLObject/paramstyles/sqlobject/main.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/main.py	2006-09-06 14:47:06 UTC (rev 1909)
+++ home/phd/SQLObject/paramstyles/sqlobject/main.py	2006-09-06 14:49:00 UTC (rev 1910)
@@ -1280,10 +1280,9 @@
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
         if isinstance(value, unicode):
-            for key, column in cls.sqlmeta.columns.items():
-                if (key == name) and isinstance(column, col.SOUnicodeCol):
-                    value = value.encode(column.dbEncoding)
-                    break
+            column = cls.sqlmeta.columns[name]
+            if isinstance(column, col.SOUnicodeCol):
+                value = value.encode(column.dbEncoding)
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +

[SQL-CVS] r1909 - SQLObject/branches/0.7-bugfix/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-06 08:47:06 -0600 (Wed, 06 Sep 2006)
New Revision: 1909

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/main.py
Log:
No need to loop over the "columns" dictionary - "name" is exactly a key for the dictionary.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/main.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/main.py	2006-09-06 14:46:32 UTC (rev 1908)
+++ SQLObject/branches/0.7-bugfix/sqlobject/main.py	2006-09-06 14:47:06 UTC (rev 1909)
@@ -1256,10 +1256,9 @@
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
         if isinstance(value, unicode):
-            for key, column in cls.sqlmeta.columns.items():
-                if (key == name) and isinstance(column, col.SOUnicodeCol):
-                    value = value.encode(column.dbEncoding)
-                    break
+            column = cls.sqlmeta.columns[name]
+            if isinstance(column, col.SOUnicodeCol):
+                value = value.encode(column.dbEncoding)
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +

[SQL-CVS] r1908 - SQLObject/trunk/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-06 08:46:32 -0600 (Wed, 06 Sep 2006)
New Revision: 1908

Modified:
   SQLObject/trunk/sqlobject/main.py
Log:
No need to loop over the "columns" dictionary - "name" is exactly a key for the dictionary.


Modified: SQLObject/trunk/sqlobject/main.py
===================================================================
--- SQLObject/trunk/sqlobject/main.py	2006-09-06 03:53:46 UTC (rev 1907)
+++ SQLObject/trunk/sqlobject/main.py	2006-09-06 14:46:32 UTC (rev 1908)
@@ -1280,10 +1280,9 @@
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
         if isinstance(value, unicode):
-            for key, column in cls.sqlmeta.columns.items():
-                if (key == name) and isinstance(column, col.SOUnicodeCol):
-                    value = value.encode(column.dbEncoding)
-                    break
+            column = cls.sqlmeta.columns[name]
+            if isinstance(column, col.SOUnicodeCol):
+                value = value.encode(column.dbEncoding)
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +

[SQL-CVS] [ sqlobject-Bugs-1496014 ] None in enumValues fails

[SourceForge.net <no...@so...>]

Bugs item #1496014, was opened at 2006-05-27 16:42
Message generated for change (Comment added) made by nitwit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MySQL
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Muller (nitwit)
Assigned to: Nobody/Anonymous (nobody)
Summary: None in enumValues fails

Initial Comment:
SQLObject-0.7.1b1

MySQL does not allow NULL inside the ENUM statemnt, so
the construction
EnumCol(enumValues=['a','b',None],default=None) will fail.

Since this construction works fine with sqlite and
postgresql, this is an issue. The attached patch fixes
the problem here.



----------------------------------------------------------------------

>Comment By: Neil Muller (nitwit)
Date: 2006-09-05 23:33

Message:
Logged In: YES 
user_id=698097

The second issue only applies if a postgresql database is
being accessed without using sqlobject as well.

he check constraint approach used doesn't work as expected
for postgresql. 
  EnumCol(enumValues=['a','b',None],default=None) 
produces something like:
  create table t (c1 varchar(2) check (c1 in ('a','b',NULL)));
However: 
   insert into t values ('1');
will succeed, because of how postgresql interprets
conditions involving NULL, as discussed in the message I
linked to. Similiar issues may arise with other databases.

However, since the call succeeds, a documentation note is
probably adequate. I've attached a possible patch to
SQLObject.txt as enum_doc_patch, although this probably
needs furtehr work.



----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-09-05 23:16

Message:
Logged In: YES 
user_id=698097

I've unfortunately combined two issues here, and I'll agree
that the second patch is incorrect.

There is an actual bug here. The current sqlobject logic
breaks on mysql:
   The construction:
 EnumCol(enumValues=['a','b',None],default=None) 
  maps to 
 CREATE TABLE t (c1 ENUM ('a','b',NULL)); 
which is not valid for MySQL, which wants NULL's for ENUM
columns handled as NULL constraints. This makes using None
in the EnumCol impossible for MySQL. The mysql_enum patch
attached aims to create a suitable constraint if None is
present EnumCol.


----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-05 15:57

Message:
Logged In: YES 
user_id=4799

This contradicts to Python philoshy "We all are grown-ups
people". If you know None (NULL) in enums is such a bad idea
- just dont use it. But forcibly remove it when the user
clearly states "I want my Nones here" is too much. Instead
of such removing write a documentation patch and clearly
explain the caveats.

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-05-29 22:39

Message:
Logged In: YES 
user_id=698097

I was pointed at
http://archives.postgresql.org/pgsql-sql/2004-12/msg00065.php,
which illustrates that NULL in the check constraint approach
used to implement EnumCol for postges and other databases
behave in an unexpected way due to the three state logic SQL
uses. Thus a believe this second patch, which excludes Nones
from all the database backends should be prefferred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1496014 ] None in enumValues fails

[SourceForge.net <no...@so...>]

Bugs item #1496014, was opened at 2006-05-27 16:42
Message generated for change (Comment added) made by nitwit
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MySQL
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Muller (nitwit)
Assigned to: Nobody/Anonymous (nobody)
Summary: None in enumValues fails

Initial Comment:
SQLObject-0.7.1b1

MySQL does not allow NULL inside the ENUM statemnt, so
the construction
EnumCol(enumValues=['a','b',None],default=None) will fail.

Since this construction works fine with sqlite and
postgresql, this is an issue. The attached patch fixes
the problem here.



----------------------------------------------------------------------

>Comment By: Neil Muller (nitwit)
Date: 2006-09-05 23:16

Message:
Logged In: YES 
user_id=698097

I've unfortunately combined two issues here, and I'll agree
that the second patch is incorrect.

There is an actual bug here. The current sqlobject logic
breaks on mysql:
   The construction:
 EnumCol(enumValues=['a','b',None],default=None) 
  maps to 
 CREATE TABLE t (c1 ENUM ('a','b',NULL)); 
which is not valid for MySQL, which wants NULL's for ENUM
columns handled as NULL constraints. This makes using None
in the EnumCol impossible for MySQL. The mysql_enum patch
attached aims to create a suitable constraint if None is
present EnumCol.


----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-09-05 15:57

Message:
Logged In: YES 
user_id=4799

This contradicts to Python philoshy "We all are grown-ups
people". If you know None (NULL) in enums is such a bad idea
- just dont use it. But forcibly remove it when the user
clearly states "I want my Nones here" is too much. Instead
of such removing write a documentation patch and clearly
explain the caveats.

----------------------------------------------------------------------

Comment By: Neil Muller (nitwit)
Date: 2006-05-29 22:39

Message:
Logged In: YES 
user_id=698097

I was pointed at
http://archives.postgresql.org/pgsql-sql/2004-12/msg00065.php,
which illustrates that NULL in the check constraint approach
used to implement EnumCol for postges and other databases
behave in an unexpected way due to the three state logic SQL
uses. Thus a believe this second patch, which excludes Nones
from all the database backends should be prefferred.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1496014&group_id=74338

[SQL-CVS] r1906 - home/phd/SQLObject/paramstyles/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-05 09:24:45 -0600 (Tue, 05 Sep 2006)
New Revision: 1906

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/main.py
Log:
Merged patches from the revisions 1903:1905 from the trunk

Modified: home/phd/SQLObject/paramstyles/sqlobject/main.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/main.py	2006-09-05 15:24:05 UTC (rev 1905)
+++ home/phd/SQLObject/paramstyles/sqlobject/main.py	2006-09-05 15:24:45 UTC (rev 1906)
@@ -1279,10 +1279,11 @@
         return getID(obj)
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
-        for key, column in cls.sqlmeta.columns.items():
-            if (key == name) and isinstance(column, col.SOUnicodeCol):
-                if isinstance(value, unicode):
+        if isinstance(value, unicode):
+            for key, column in cls.sqlmeta.columns.items():
+                if (key == name) and isinstance(column, col.SOUnicodeCol):
                     value = value.encode(column.dbEncoding)
+                    break
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +

[SQL-CVS] r1905 - SQLObject/branches/0.7-bugfix/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-05 09:24:05 -0600 (Tue, 05 Sep 2006)
New Revision: 1905

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/main.py
Log:
Minor optimization - moved the condition out of the loop, used break.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/main.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/main.py	2006-09-05 15:23:48 UTC (rev 1904)
+++ SQLObject/branches/0.7-bugfix/sqlobject/main.py	2006-09-05 15:24:05 UTC (rev 1905)
@@ -1255,10 +1255,11 @@
         return getID(obj)
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
-        for key, column in cls.sqlmeta.columns.items():
-            if (key == name) and isinstance(column, col.SOUnicodeCol):
-                if isinstance(value, unicode):
+        if isinstance(value, unicode):
+            for key, column in cls.sqlmeta.columns.items():
+                if (key == name) and isinstance(column, col.SOUnicodeCol):
                     value = value.encode(column.dbEncoding)
+                    break
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +

[SQL-CVS] r1904 - SQLObject/trunk/sqlobject

[<sub...@co...>]

Author: phd
Date: 2006-09-05 09:23:48 -0600 (Tue, 05 Sep 2006)
New Revision: 1904

Modified:
   SQLObject/trunk/sqlobject/main.py
Log:
Minor optimization - moved the condition out of the loop, used break.


Modified: SQLObject/trunk/sqlobject/main.py
===================================================================
--- SQLObject/trunk/sqlobject/main.py	2006-09-05 14:07:44 UTC (rev 1903)
+++ SQLObject/trunk/sqlobject/main.py	2006-09-05 15:23:48 UTC (rev 1904)
@@ -1279,10 +1279,11 @@
         return getID(obj)
 
     def _findAlternateID(cls, name, dbName, value, connection=None):
-        for key, column in cls.sqlmeta.columns.items():
-            if (key == name) and isinstance(column, col.SOUnicodeCol):
-                if isinstance(value, unicode):
+        if isinstance(value, unicode):
+            for key, column in cls.sqlmeta.columns.items():
+                if (key == name) and isinstance(column, col.SOUnicodeCol):
                     value = value.encode(column.dbEncoding)
+                    break
         return (connection or cls._connection)._SO_selectOneAlt(
             cls,
             [cls.sqlmeta.idName] +