sqlobject-cvs — CVS notification

[SQL-CVS] [ sqlobject-Bugs-1665322 ] InheritableSQLObject childName column in sqlmeta.columns

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

Bugs item #1665322, was opened at 2007-02-21 12:30
Message generated for change (Comment added) made by llucax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1665322&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: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Leandro Lucarella (llucax)
Assigned to: Oleg Broytmann (phd)
Summary: InheritableSQLObject childName column in sqlmeta.columns

Initial Comment:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject

__connection__ = 'sqlite:///:memory:'

class Base(InheritableSQLObject):
        base = IntCol()
Base.createTable()

print j.Base.sqlmeta.columns
{'base': <SOIntCol base>, 'childName': <SOStringCol childName default=None>}

I think 'childName' should not be "listed" in sqlmeta.columns because it's a SQLObject "artifact" (just like 'id' column).

This complicate automatic conversion from SQLObject to other types (like TurboJson's jsonify_sqlobject() function).

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

>Comment By: Leandro Lucarella (llucax)
Date: 2007-08-21 10:00

Message:
Logged In: YES 
user_id=240225
Originator: YES

It adds a new method, but why do you say that changes the existing ones?
asDict() only changes for inheritable objects (for normal objects asDict()
works exactly the same) , but it was broken anyways, so I don't see how
this change could break any existing code, if existing code can't use
asDict() for inheritable objects.

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

Comment By: Oleg Broytmann (phd)
Date: 2007-08-21 09:54

Message:
Logged In: YES 
user_id=4799
Originator: NO

The patch changes the public API - it adds a new method and changes the
existing ones - hence it can be applied only to the trunk. I also changed
the patch - mostly changed names. Applied and committed in the revisions
2885, 2886.

PS. We use py.test, not nosetest. :)

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-08-20 22:57

Message:
Logged In: YES 
user_id=240225
Originator: YES

Here are some untested testcases (I don't know how to use nosetest :)

They test asDict(), not getColumn() directly.
File Added: sqlobject.r2871.asDict.tests.patch

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-08-20 22:55

Message:
Logged In: YES 
user_id=240225
Originator: YES

This is no exactly a great patch, and doesn't fix the base problem, but it
provides a consistent way to get all the meaningfull columns for a user.

The patch adds a function getColumns() to the sqlmeta object (and the
inheritable version), that allways get all the columns for a class
(including parent classes), excluding for the 'childName' column but
including the 'id' column.

This patch makes asDict() function use getColumns(), so there is no need
to override it in the inheritable sqlmeta class. This makes asDict() to
work properly on inheritable sqlobjects, avoiding the "AttributeError:
'SomeSQLObject' object has no attribute '_SO_val_childName'" error.
File Added: sqlobject.r2871.getColumns.patch

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-28 08:15

Message:
Logged In: YES 
user_id=4799
Originator: NO

Reopened; see bug 1665328 for details. Now waiting for a patch...

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 10:22

Message:
Logged In: YES 
user_id=240225
Originator: YES

Because it doesn't behave like a real column (1665328 is an example, a
regular column is inherited to all it's descendant, and the "None" behavior
is another example too) and it's not user data.

But I understand you don't see a great advantage on fixing it, i'll try to
work on it when I have some time if you agree something is wrong and are
interested in patches for this... (and don't want to work on a patch that
it will not be accepted).

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-23 09:35

Message:
Logged In: YES 
user_id=4799
Originator: NO

Why is it a bug? It works as advertised. It is a real column, and it
presents in .columns.

In any case it would be so hard to fix, and fixing it gives so little
advantage - I am not going to work on it. But I can test a patch if one
appears.

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 09:08

Message:
Logged In: YES 
user_id=240225
Originator: YES

Ok, it should be hard to fix, but don't you agree it's a bug? Shouldn't be
emulated like the "id" column? It's not user data.

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-22 16:41

Message:
Logged In: YES 
user_id=4799
Originator: NO

SQLObject emulates "id" columns. Unlike that fictional column childName is
a real column. There is no way to remove it from .columns.

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

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

[SQL-CVS] [ sqlobject-Bugs-1665322 ] InheritableSQLObject childName column in sqlmeta.columns

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

Bugs item #1665322, was opened at 2007-02-21 18:30
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1665322&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: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Leandro Lucarella (llucax)
Assigned to: Oleg Broytmann (phd)
Summary: InheritableSQLObject childName column in sqlmeta.columns

Initial Comment:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject

__connection__ = 'sqlite:///:memory:'

class Base(InheritableSQLObject):
        base = IntCol()
Base.createTable()

print j.Base.sqlmeta.columns
{'base': <SOIntCol base>, 'childName': <SOStringCol childName default=None>}

I think 'childName' should not be "listed" in sqlmeta.columns because it's a SQLObject "artifact" (just like 'id' column).

This complicate automatic conversion from SQLObject to other types (like TurboJson's jsonify_sqlobject() function).

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

>Comment By: Oleg Broytmann (phd)
Date: 2007-08-21 16:54

Message:
Logged In: YES 
user_id=4799
Originator: NO

The patch changes the public API - it adds a new method and changes the
existing ones - hence it can be applied only to the trunk. I also changed
the patch - mostly changed names. Applied and committed in the revisions
2885, 2886.

PS. We use py.test, not nosetest. :)

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-08-21 05:57

Message:
Logged In: YES 
user_id=240225
Originator: YES

Here are some untested testcases (I don't know how to use nosetest :)

They test asDict(), not getColumn() directly.
File Added: sqlobject.r2871.asDict.tests.patch

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-08-21 05:55

Message:
Logged In: YES 
user_id=240225
Originator: YES

This is no exactly a great patch, and doesn't fix the base problem, but it
provides a consistent way to get all the meaningfull columns for a user.

The patch adds a function getColumns() to the sqlmeta object (and the
inheritable version), that allways get all the columns for a class
(including parent classes), excluding for the 'childName' column but
including the 'id' column.

This patch makes asDict() function use getColumns(), so there is no need
to override it in the inheritable sqlmeta class. This makes asDict() to
work properly on inheritable sqlobjects, avoiding the "AttributeError:
'SomeSQLObject' object has no attribute '_SO_val_childName'" error.
File Added: sqlobject.r2871.getColumns.patch

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-28 14:15

Message:
Logged In: YES 
user_id=4799
Originator: NO

Reopened; see bug 1665328 for details. Now waiting for a patch...

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 16:22

Message:
Logged In: YES 
user_id=240225
Originator: YES

Because it doesn't behave like a real column (1665328 is an example, a
regular column is inherited to all it's descendant, and the "None" behavior
is another example too) and it's not user data.

But I understand you don't see a great advantage on fixing it, i'll try to
work on it when I have some time if you agree something is wrong and are
interested in patches for this... (and don't want to work on a patch that
it will not be accepted).

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-23 15:35

Message:
Logged In: YES 
user_id=4799
Originator: NO

Why is it a bug? It works as advertised. It is a real column, and it
presents in .columns.

In any case it would be so hard to fix, and fixing it gives so little
advantage - I am not going to work on it. But I can test a patch if one
appears.

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 15:08

Message:
Logged In: YES 
user_id=240225
Originator: YES

Ok, it should be hard to fix, but don't you agree it's a bug? Shouldn't be
emulated like the "id" column? It's not user data.

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-22 22:41

Message:
Logged In: YES 
user_id=4799
Originator: NO

SQLObject emulates "id" columns. Unlike that fictional column childName is
a real column. There is no way to remove it from .columns.

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

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

[SQL-CVS] r2886 - SQLObject/docs

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

Author: phd
Date: 2007-08-21 06:54:14 -0600 (Tue, 21 Aug 2007)
New Revision: 2886

Modified:
   SQLObject/docs/News.txt
Log:
Added sqlmeta.getColumns(). sqlmeta.asDict() now uses getColumns().


Modified: SQLObject/docs/News.txt
===================================================================
--- SQLObject/docs/News.txt	2007-08-21 12:53:06 UTC (rev 2885)
+++ SQLObject/docs/News.txt	2007-08-21 12:54:14 UTC (rev 2886)
@@ -41,6 +41,12 @@
 
 * Added ViewSQLObject.
 
+* Added sqlmeta.getColumns() to get all the columns for a class (including
+  parent classes), excluding the column 'childName' indncluding the column
+  'id'. sqlmeta.asDict() now uses getColumns(), so there is no need to
+  override it in the inheritable sqlmeta class; this makes asDict() to work
+  properly on inheritable sqlobjects.
+
 SQLObject 0.9.2
 ===============
 

[SQL-CVS] r2885 - in SQLObject/trunk/sqlobject: . inheritance inheritance/tests tests

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

Author: phd
Date: 2007-08-21 06:53:06 -0600 (Tue, 21 Aug 2007)
New Revision: 2885

Added:
   SQLObject/trunk/sqlobject/inheritance/tests/test_asdict.py
   SQLObject/trunk/sqlobject/tests/test_asdict.py
Modified:
   SQLObject/trunk/sqlobject/inheritance/__init__.py
   SQLObject/trunk/sqlobject/main.py
Log:
Added sqlmeta.getColumns(). sqlmeta.asDict() now uses getColumns().


Modified: SQLObject/trunk/sqlobject/inheritance/__init__.py
===================================================================
--- SQLObject/trunk/sqlobject/inheritance/__init__.py	2007-08-21 08:15:42 UTC (rev 2884)
+++ SQLObject/trunk/sqlobject/inheritance/__init__.py	2007-08-21 12:53:06 UTC (rev 2885)
@@ -201,12 +201,11 @@
             sm = sm.parentClass.sqlmeta
         return columns
 
-    def asDict(sqlmeta):
-        result = {}
-        for key in sqlmeta.getAllColumns():
-            result[key] = getattr(sqlmeta.instance, key)
-        result['id'] = sqlmeta.instance.id
-        return result
+    def getColumns(sqlmeta):
+        columns = sqlmeta.getAllColumns()
+        if columns.has_key('childName'):
+            del columns['childName']
+        return columns
 
 
 class InheritableSQLObject(SQLObject):

Added: SQLObject/trunk/sqlobject/inheritance/tests/test_asdict.py
===================================================================
--- SQLObject/trunk/sqlobject/inheritance/tests/test_asdict.py	                        (rev 0)
+++ SQLObject/trunk/sqlobject/inheritance/tests/test_asdict.py	2007-08-21 12:53:06 UTC (rev 2885)
@@ -0,0 +1,31 @@
+from sqlobject import *
+from sqlobject.inheritance import *
+from sqlobject.tests.dbtest import *
+
+########################################
+## sqlmeta.asDict
+########################################
+
+class InheritablePerson(InheritableSQLObject):
+    first = StringCol()
+    last = StringCol(alternateID=True, length=255)
+
+class Boss(InheritablePerson):
+    department = StringCol()
+
+class Employee(InheritablePerson):
+    _inheritable = False
+    position = StringCol()
+
+def test_asDict():
+    setupClass([InheritablePerson, Boss, Employee])
+    InheritablePerson(first='Oneof', last='Authors')
+    Boss(first='Boss', last='The', department='Dep')
+    Employee(first='Project', last='Leader', position='Project leader')
+
+    assert InheritablePerson.get(1).sqlmeta.asDict() == \
+        dict(first='Oneof', last='Authors', id=1)
+    assert InheritablePerson.get(2).sqlmeta.asDict() == \
+        dict(first='Boss', last='The', department='Dep', id=2)
+    assert InheritablePerson.get(3).sqlmeta.asDict() == \
+        dict(first='Project', last='Leader', position='Project leader', id=3)

Modified: SQLObject/trunk/sqlobject/main.py
===================================================================
--- SQLObject/trunk/sqlobject/main.py	2007-08-21 08:15:42 UTC (rev 2884)
+++ SQLObject/trunk/sqlobject/main.py	2007-08-21 12:53:06 UTC (rev 2885)
@@ -609,12 +609,15 @@
     ## Utility methods
     ########################################
 
+    def getColumns(sqlmeta):
+        return sqlmeta.columns.copy()
+
     def asDict(self):
         """
         Return the object as a dictionary of columns to values.
         """
         result = {}
-        for key in self.columns:
+        for key in self.getColumns():
             result[key] = getattr(self.instance, key)
         result['id'] = self.instance.id
         return result

Added: SQLObject/trunk/sqlobject/tests/test_asdict.py
===================================================================
--- SQLObject/trunk/sqlobject/tests/test_asdict.py	                        (rev 0)
+++ SQLObject/trunk/sqlobject/tests/test_asdict.py	2007-08-21 12:53:06 UTC (rev 2885)
@@ -0,0 +1,15 @@
+from sqlobject import *
+from sqlobject.tests.dbtest import *
+
+########################################
+## sqlmeta.asDict()
+########################################
+
+class TestAsDict(SQLObject):
+    name = StringCol(length=10)
+    name2 = StringCol(length=10)
+
+def test_asDict():
+    setupClass(TestAsDict)
+    t1 = TestAsDict(name='one', name2='1')
+    assert t1.sqlmeta.asDict() == dict(name='one', name2='1', id=1)

[SQL-CVS] r2884 - SQLObject/docs

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

Author: phd
Date: 2007-08-21 02:15:42 -0600 (Tue, 21 Aug 2007)
New Revision: 2884

Modified:
   SQLObject/docs/News.txt
Log:
Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
(so that the default type for the columns in  MySQL is BLOB, not TEXT).


Modified: SQLObject/docs/News.txt
===================================================================
--- SQLObject/docs/News.txt	2007-08-21 08:15:28 UTC (rev 2883)
+++ SQLObject/docs/News.txt	2007-08-21 08:15:42 UTC (rev 2884)
@@ -41,6 +41,9 @@
 
 * Added ViewSQLObject.
 
+SQLObject 0.9.2
+===============
+
 SQLObject 0.9.1
 ===============
 
@@ -108,6 +111,11 @@
 
 * idName can be inherited from the parent sqlmeta class.
 
+SQLObject 0.8.6
+===============
+
+* A number of changes ported from `SQLObject 0.7.9`_.
+
 SQLObject 0.8.5
 ===============
 
@@ -275,6 +283,15 @@
 
 * Fixed aggregators and accumulators with inheritance.
 
+SQLObject 0.7.9
+===============
+
+Other Changes
+-------------
+
+* Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
+  (so that the default type for the columns in  MySQL is BLOB, not TEXT).
+
 SQLObject 0.7.8
 ===============
 

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

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

Author: phd
Date: 2007-08-21 02:15:28 -0600 (Tue, 21 Aug 2007)
New Revision: 2883

Modified:
   SQLObject/trunk/sqlobject/col.py
Log:
Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
(so that the default type for the columns in  MySQL is BLOB, not TEXT).


Modified: SQLObject/trunk/sqlobject/col.py
===================================================================
--- SQLObject/trunk/sqlobject/col.py	2007-08-21 08:15:08 UTC (rev 2882)
+++ SQLObject/trunk/sqlobject/col.py	2007-08-21 08:15:28 UTC (rev 2883)
@@ -1396,6 +1396,11 @@
         return binary
 
 class SOBLOBCol(SOStringCol):
+    def __init__(self, **kw):
+        # Change the default from 'auto' to False - this is a (mostly) binary column
+        if 'varchar' not in kw: kw['varchar'] = False
+        super(SOBLOBCol, self).__init__(**kw)
+
     def createValidators(self):
         return [BinaryValidator(name=self.name)] + \
             super(SOBLOBCol, self).createValidators()

[SQL-CVS] r2882 - in SQLObject/branches/0.9: docs sqlobject

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

Author: phd
Date: 2007-08-21 02:15:08 -0600 (Tue, 21 Aug 2007)
New Revision: 2882

Modified:
   SQLObject/branches/0.9/docs/News.txt
   SQLObject/branches/0.9/sqlobject/col.py
Log:
Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
(so that the default type for the columns in  MySQL is BLOB, not TEXT).


Modified: SQLObject/branches/0.9/docs/News.txt
===================================================================
--- SQLObject/branches/0.9/docs/News.txt	2007-08-21 08:14:43 UTC (rev 2881)
+++ SQLObject/branches/0.9/docs/News.txt	2007-08-21 08:15:08 UTC (rev 2882)
@@ -7,6 +7,9 @@
 
 .. _start:
 
+SQLObject 0.9.2
+===============
+
 SQLObject 0.9.1
 ===============
 
@@ -76,6 +79,11 @@
 
 * idName can be inherited from the parent sqlmeta class.
 
+SQLObject 0.8.6
+===============
+
+* A number of changes ported from `SQLObject 0.7.9`_.
+
 SQLObject 0.8.5
 ===============
 
@@ -247,6 +255,15 @@
 
 * Fixed aggregators and accumulators with inheritance.
 
+SQLObject 0.7.9
+===============
+
+Other Changes
+-------------
+
+* Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
+  (so that the default type for the columns in  MySQL is BLOB, not TEXT).
+
 SQLObject 0.7.8
 ===============
 

Modified: SQLObject/branches/0.9/sqlobject/col.py
===================================================================
--- SQLObject/branches/0.9/sqlobject/col.py	2007-08-21 08:14:43 UTC (rev 2881)
+++ SQLObject/branches/0.9/sqlobject/col.py	2007-08-21 08:15:08 UTC (rev 2882)
@@ -1396,6 +1396,11 @@
         return binary
 
 class SOBLOBCol(SOStringCol):
+    def __init__(self, **kw):
+        # Change the default from 'auto' to False - this is a (mostly) binary column
+        if 'varchar' not in kw: kw['varchar'] = False
+        super(SOBLOBCol, self).__init__(**kw)
+
     def createValidators(self):
         return [BinaryValidator(name=self.name)] + \
             super(SOBLOBCol, self).createValidators()

[SQL-CVS] r2881 - in SQLObject/branches/0.8: docs sqlobject

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

Author: phd
Date: 2007-08-21 02:14:43 -0600 (Tue, 21 Aug 2007)
New Revision: 2881

Modified:
   SQLObject/branches/0.8/docs/News.txt
   SQLObject/branches/0.8/sqlobject/col.py
Log:
Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
(so that the default type for the columns in  MySQL is BLOB, not TEXT).


Modified: SQLObject/branches/0.8/docs/News.txt
===================================================================
--- SQLObject/branches/0.8/docs/News.txt	2007-08-21 08:13:30 UTC (rev 2880)
+++ SQLObject/branches/0.8/docs/News.txt	2007-08-21 08:14:43 UTC (rev 2881)
@@ -7,6 +7,11 @@
 
 .. _start:
 
+SQLObject 0.8.6
+===============
+
+* A number of changes ported from `SQLObject 0.7.9`_.
+
 SQLObject 0.8.5
 ===============
 
@@ -178,6 +183,15 @@
 
 * Fixed aggregators and accumulators with inheritance.
 
+SQLObject 0.7.9
+===============
+
+Other Changes
+-------------
+
+* Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
+  (so that the default type for the columns in  MySQL is BLOB, not TEXT).
+
 SQLObject 0.7.8
 ===============
 

Modified: SQLObject/branches/0.8/sqlobject/col.py
===================================================================
--- SQLObject/branches/0.8/sqlobject/col.py	2007-08-21 08:13:30 UTC (rev 2880)
+++ SQLObject/branches/0.8/sqlobject/col.py	2007-08-21 08:14:43 UTC (rev 2881)
@@ -1294,6 +1294,11 @@
         return binary
 
 class SOBLOBCol(SOStringCol):
+    def __init__(self, **kw):
+        # Change the default from 'auto' to False - this is a (mostly) binary column
+        if 'varchar' not in kw: kw['varchar'] = False
+        super(SOBLOBCol, self).__init__(**kw)
+
     def createValidators(self):
         return [BinaryValidator(name=self.name)] + \
             super(SOBLOBCol, self).createValidators()

[SQL-CVS] r2880 - in SQLObject/branches/0.7: docs sqlobject

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

Author: phd
Date: 2007-08-21 02:13:30 -0600 (Tue, 21 Aug 2007)
New Revision: 2880

Modified:
   SQLObject/branches/0.7/docs/News.txt
   SQLObject/branches/0.7/sqlobject/col.py
Log:
Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
(so that the default type for the columns in  MySQL is BLOB, not TEXT).


Modified: SQLObject/branches/0.7/docs/News.txt
===================================================================
--- SQLObject/branches/0.7/docs/News.txt	2007-08-21 07:39:42 UTC (rev 2879)
+++ SQLObject/branches/0.7/docs/News.txt	2007-08-21 08:13:30 UTC (rev 2880)
@@ -7,6 +7,15 @@
 
 .. _start:
 
+SQLObject 0.7.9
+===============
+
+Other Changes
+-------------
+
+* Changed the default value for 'varchar' in BLOBColumns from 'auto' to False
+  (so that the default type for the columns in  MySQL is BLOB, not TEXT).
+
 SQLObject 0.7.8
 ===============
 

Modified: SQLObject/branches/0.7/sqlobject/col.py
===================================================================
--- SQLObject/branches/0.7/sqlobject/col.py	2007-08-21 07:39:42 UTC (rev 2879)
+++ SQLObject/branches/0.7/sqlobject/col.py	2007-08-21 08:13:30 UTC (rev 2880)
@@ -1236,6 +1236,11 @@
         return binary
 
 class SOBLOBCol(SOStringCol):
+    def __init__(self, **kw):
+        # Change the default from 'auto' to False - this is a (mostly) binary column
+        if 'varchar' not in kw: kw['varchar'] = False
+        super(SOBLOBCol, self).__init__(**kw)
+
     def createValidators(self):
         return [BinaryValidator(name=self.name)] + \
             super(SOBLOBCol, self).createValidators()

[SQL-CVS] r2879 - SQLObject/docs

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

Author: phd
Date: 2007-08-21 01:39:42 -0600 (Tue, 21 Aug 2007)
New Revision: 2879

Modified:
   SQLObject/docs/SQLObject.txt
Log:
Minor documentation update - MyTable.select() always meant
SELECT my_table.*, not SELECT *, even for joins.


Modified: SQLObject/docs/SQLObject.txt
===================================================================
--- SQLObject/docs/SQLObject.txt	2007-08-21 07:39:20 UTC (rev 2878)
+++ SQLObject/docs/SQLObject.txt	2007-08-21 07:39:42 UTC (rev 2879)
@@ -1909,7 +1909,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, table1
+    SELECT my_table.* FROM my_table, table1
     LEFT JOIN table2 ON table1.name = table2.value;
 
 .. _FAQ: FAQ.html#how-can-i-do-a-left-join
@@ -1923,7 +1923,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table
+    SELECT my_table.* FROM my_table
     LEFT JOIN table2 ON my_table.name = table1.value;
 
 The join argument for .select() can be a JOIN() or a sequence (list/tuple)
@@ -1948,7 +1948,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, my_table AS my_table_alias
+    SELECT my_table.* FROM my_table, my_table AS my_table_alias
     WHERE my_table.name = my_table_alias.value;
 
 Can I use a JOIN() with aliases?
@@ -1964,7 +1964,7 @@
 
 will result in the query::
 
-    SELECT * FROM other_table,
+    SELECT my_table.* FROM other_table,
         my_table LEFT JOIN other_table AS other_table_alias
     WHERE my_table.name == other_table.value AND
         my_table.col1 = other_table_alias.col2.

[SQL-CVS] r2878 - SQLObject/branches/0.9/docs

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

Author: phd
Date: 2007-08-21 01:39:20 -0600 (Tue, 21 Aug 2007)
New Revision: 2878

Modified:
   SQLObject/branches/0.9/docs/SQLObject.txt
Log:
Minor documentation update - MyTable.select() always meant
SELECT my_table.*, not SELECT *, even for joins.


Modified: SQLObject/branches/0.9/docs/SQLObject.txt
===================================================================
--- SQLObject/branches/0.9/docs/SQLObject.txt	2007-08-21 07:39:04 UTC (rev 2877)
+++ SQLObject/branches/0.9/docs/SQLObject.txt	2007-08-21 07:39:20 UTC (rev 2878)
@@ -1909,7 +1909,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, table1
+    SELECT my_table.* FROM my_table, table1
     LEFT JOIN table2 ON table1.name = table2.value;
 
 .. _FAQ: FAQ.html#how-can-i-do-a-left-join
@@ -1923,7 +1923,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table
+    SELECT my_table.* FROM my_table
     LEFT JOIN table2 ON my_table.name = table1.value;
 
 The join argument for .select() can be a JOIN() or a sequence (list/tuple)
@@ -1948,7 +1948,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, my_table AS my_table_alias
+    SELECT my_table.* FROM my_table, my_table AS my_table_alias
     WHERE my_table.name = my_table_alias.value;
 
 Can I use a JOIN() with aliases?
@@ -1964,7 +1964,7 @@
 
 will result in the query::
 
-    SELECT * FROM other_table,
+    SELECT my_table.* FROM other_table,
         my_table LEFT JOIN other_table AS other_table_alias
     WHERE my_table.name == other_table.value AND
         my_table.col1 = other_table_alias.col2.

[SQL-CVS] r2877 - SQLObject/branches/0.8/docs

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

Author: phd
Date: 2007-08-21 01:39:04 -0600 (Tue, 21 Aug 2007)
New Revision: 2877

Modified:
   SQLObject/branches/0.8/docs/SQLObject.txt
Log:
Minor documentation update - MyTable.select() always meant
SELECT my_table.*, not SELECT *, even for joins.


Modified: SQLObject/branches/0.8/docs/SQLObject.txt
===================================================================
--- SQLObject/branches/0.8/docs/SQLObject.txt	2007-08-21 07:38:43 UTC (rev 2876)
+++ SQLObject/branches/0.8/docs/SQLObject.txt	2007-08-21 07:39:04 UTC (rev 2877)
@@ -1817,7 +1817,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, table1
+    SELECT my_table.* FROM my_table, table1
     LEFT JOIN table2 ON table1.name = table2.value;
 
 .. _FAQ: FAQ.html#how-can-i-do-a-left-join
@@ -1831,7 +1831,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table
+    SELECT my_table.* FROM my_table
     LEFT JOIN table2 ON my_table.name = table1.value;
 
 The join argument for .select() can be a JOIN() or a sequence (list/tuple)
@@ -1856,7 +1856,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, my_table AS my_table_alias
+    SELECT my_table.* FROM my_table, my_table AS my_table_alias
     WHERE my_table.name = my_table_alias.value;
 
 Can I use a JOIN() with aliases?
@@ -1872,7 +1872,7 @@
 
 will result in the query::
 
-    SELECT * FROM other_table,
+    SELECT my_table.* FROM other_table,
         my_table LEFT JOIN other_table AS other_table_alias
     WHERE my_table.name == other_table.value AND
         my_table.col1 = other_table_alias.col2.

[SQL-CVS] r2876 - SQLObject/branches/0.7/docs

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

Author: phd
Date: 2007-08-21 01:38:43 -0600 (Tue, 21 Aug 2007)
New Revision: 2876

Modified:
   SQLObject/branches/0.7/docs/SQLObject.txt
Log:
Minor documentation update - MyTable.select() always meant
SELECT my_table.*, not SELECT *, even for joins.


Modified: SQLObject/branches/0.7/docs/SQLObject.txt
===================================================================
--- SQLObject/branches/0.7/docs/SQLObject.txt	2007-08-21 07:31:44 UTC (rev 2875)
+++ SQLObject/branches/0.7/docs/SQLObject.txt	2007-08-21 07:38:43 UTC (rev 2876)
@@ -1737,7 +1737,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, table1
+    SELECT my_table.* FROM my_table, table1
     LEFT JOIN table2 ON table1.name = table2.value;
 
 .. _FAQ: FAQ.html#how-can-i-do-a-left-join
@@ -1751,7 +1751,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table
+    SELECT my_table.* FROM my_table
     LEFT JOIN table2 ON my_table.name = table1.value;
 
 The join argument for .select() can be a JOIN() or a sequence (list/tuple)
@@ -1776,7 +1776,7 @@
 
 will generate the query::
 
-    SELECT * FROM my_table, my_table AS my_table_alias
+    SELECT my_table.* FROM my_table, my_table AS my_table_alias
     WHERE my_table.name = my_table_alias.value;
 
 Can I use a JOIN() with aliases?
@@ -1792,7 +1792,7 @@
 
 will result in the query::
 
-    SELECT * FROM other_table,
+    SELECT my_table.* FROM other_table,
         my_table LEFT JOIN other_table AS other_table_alias
     WHERE my_table.name == other_table.value AND
         my_table.col1 = other_table_alias.col2.

[SQL-CVS] r2875 - SQLObject/docs

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

Author: phd
Date: 2007-08-21 01:31:44 -0600 (Tue, 21 Aug 2007)
New Revision: 2875

Modified:
   SQLObject/docs/News.txt
Log:
Minor documentation update.


Modified: SQLObject/docs/News.txt
===================================================================
--- SQLObject/docs/News.txt	2007-08-21 07:30:54 UTC (rev 2874)
+++ SQLObject/docs/News.txt	2007-08-21 07:31:44 UTC (rev 2875)
@@ -51,6 +51,8 @@
 
 * Fixed misspelled methods in col.py.
 
+* A number of bugfixes ported from `SQLObject 0.7.8`_ and `SQLObject 0.8.5`_.
+
 SQLObject 0.9.0
 ===============
 
@@ -304,7 +306,7 @@
 Other Changes
 -------------
 
-* Changed string quoting style for PostgreSQL and MySQL from \' to ''.
+* Changed string quoting style for PostgreSQL and MySQL from \\' to ''.
 
 SQLObject 0.7.7
 ===============

[SQL-CVS] r2874 - SQLObject/branches/0.9/docs

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

Author: phd
Date: 2007-08-21 01:30:54 -0600 (Tue, 21 Aug 2007)
New Revision: 2874

Modified:
   SQLObject/branches/0.9/docs/News.txt
Log:
Minor fix in reST syntax - backslash is a special character and must be backslashed.


Modified: SQLObject/branches/0.9/docs/News.txt
===================================================================
--- SQLObject/branches/0.9/docs/News.txt	2007-08-21 07:30:40 UTC (rev 2873)
+++ SQLObject/branches/0.9/docs/News.txt	2007-08-21 07:30:54 UTC (rev 2874)
@@ -278,7 +278,7 @@
 Other Changes
 -------------
 
-* Changed string quoting style for PostgreSQL and MySQL from \' to ''.
+* Changed string quoting style for PostgreSQL and MySQL from \\' to ''.
 
 SQLObject 0.7.7
 ===============

[SQL-CVS] r2873 - SQLObject/branches/0.8/docs

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

Author: phd
Date: 2007-08-21 01:30:40 -0600 (Tue, 21 Aug 2007)
New Revision: 2873

Modified:
   SQLObject/branches/0.8/docs/News.txt
Log:
Minor fix in reST syntax - backslash is a special character and must be backslashed.


Modified: SQLObject/branches/0.8/docs/News.txt
===================================================================
--- SQLObject/branches/0.8/docs/News.txt	2007-08-21 07:30:17 UTC (rev 2872)
+++ SQLObject/branches/0.8/docs/News.txt	2007-08-21 07:30:40 UTC (rev 2873)
@@ -209,7 +209,7 @@
 Other Changes
 -------------
 
-* Changed string quoting style for PostgreSQL and MySQL from \' to ''.
+* Changed string quoting style for PostgreSQL and MySQL from \\' to ''.
 
 SQLObject 0.7.7
 ===============

[SQL-CVS] r2872 - SQLObject/branches/0.7/docs

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

Author: phd
Date: 2007-08-21 01:30:17 -0600 (Tue, 21 Aug 2007)
New Revision: 2872

Modified:
   SQLObject/branches/0.7/docs/News.txt
Log:
Minor fix in reST syntax - backslash is a special character and must be backslashed.


Modified: SQLObject/branches/0.7/docs/News.txt
===================================================================
--- SQLObject/branches/0.7/docs/News.txt	2007-08-17 23:43:23 UTC (rev 2871)
+++ SQLObject/branches/0.7/docs/News.txt	2007-08-21 07:30:17 UTC (rev 2872)
@@ -38,7 +38,7 @@
 Other Changes
 -------------
 
-* Changed string quoting style for PostgreSQL and MySQL from \' to ''.
+* Changed string quoting style for PostgreSQL and MySQL from \\' to ''.
 
 SQLObject 0.7.7
 ===============

[SQL-CVS] [ sqlobject-Bugs-1665322 ] InheritableSQLObject childName column in sqlmeta.columns

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

Bugs item #1665322, was opened at 2007-02-21 12:30
Message generated for change (Comment added) made by llucax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1665322&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: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Leandro Lucarella (llucax)
Assigned to: Oleg Broytmann (phd)
Summary: InheritableSQLObject childName column in sqlmeta.columns

Initial Comment:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject

__connection__ = 'sqlite:///:memory:'

class Base(InheritableSQLObject):
        base = IntCol()
Base.createTable()

print j.Base.sqlmeta.columns
{'base': <SOIntCol base>, 'childName': <SOStringCol childName default=None>}

I think 'childName' should not be "listed" in sqlmeta.columns because it's a SQLObject "artifact" (just like 'id' column).

This complicate automatic conversion from SQLObject to other types (like TurboJson's jsonify_sqlobject() function).

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

>Comment By: Leandro Lucarella (llucax)
Date: 2007-08-20 22:57

Message:
Logged In: YES 
user_id=240225
Originator: YES

Here are some untested testcases (I don't know how to use nosetest :)

They test asDict(), not getColumn() directly.
File Added: sqlobject.r2871.asDict.tests.patch

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-08-20 22:55

Message:
Logged In: YES 
user_id=240225
Originator: YES

This is no exactly a great patch, and doesn't fix the base problem, but it
provides a consistent way to get all the meaningfull columns for a user.

The patch adds a function getColumns() to the sqlmeta object (and the
inheritable version), that allways get all the columns for a class
(including parent classes), excluding for the 'childName' column but
including the 'id' column.

This patch makes asDict() function use getColumns(), so there is no need
to override it in the inheritable sqlmeta class. This makes asDict() to
work properly on inheritable sqlobjects, avoiding the "AttributeError:
'SomeSQLObject' object has no attribute '_SO_val_childName'" error.
File Added: sqlobject.r2871.getColumns.patch

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-28 08:15

Message:
Logged In: YES 
user_id=4799
Originator: NO

Reopened; see bug 1665328 for details. Now waiting for a patch...

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 10:22

Message:
Logged In: YES 
user_id=240225
Originator: YES

Because it doesn't behave like a real column (1665328 is an example, a
regular column is inherited to all it's descendant, and the "None" behavior
is another example too) and it's not user data.

But I understand you don't see a great advantage on fixing it, i'll try to
work on it when I have some time if you agree something is wrong and are
interested in patches for this... (and don't want to work on a patch that
it will not be accepted).

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-23 09:35

Message:
Logged In: YES 
user_id=4799
Originator: NO

Why is it a bug? It works as advertised. It is a real column, and it
presents in .columns.

In any case it would be so hard to fix, and fixing it gives so little
advantage - I am not going to work on it. But I can test a patch if one
appears.

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 09:08

Message:
Logged In: YES 
user_id=240225
Originator: YES

Ok, it should be hard to fix, but don't you agree it's a bug? Shouldn't be
emulated like the "id" column? It's not user data.

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-22 16:41

Message:
Logged In: YES 
user_id=4799
Originator: NO

SQLObject emulates "id" columns. Unlike that fictional column childName is
a real column. There is no way to remove it from .columns.

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

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

[SQL-CVS] [ sqlobject-Bugs-1665322 ] InheritableSQLObject childName column in sqlmeta.columns

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

Bugs item #1665322, was opened at 2007-02-21 12:30
Message generated for change (Comment added) made by llucax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1665322&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: None
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Leandro Lucarella (llucax)
Assigned to: Oleg Broytmann (phd)
Summary: InheritableSQLObject childName column in sqlmeta.columns

Initial Comment:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject

__connection__ = 'sqlite:///:memory:'

class Base(InheritableSQLObject):
        base = IntCol()
Base.createTable()

print j.Base.sqlmeta.columns
{'base': <SOIntCol base>, 'childName': <SOStringCol childName default=None>}

I think 'childName' should not be "listed" in sqlmeta.columns because it's a SQLObject "artifact" (just like 'id' column).

This complicate automatic conversion from SQLObject to other types (like TurboJson's jsonify_sqlobject() function).

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

>Comment By: Leandro Lucarella (llucax)
Date: 2007-08-20 22:55

Message:
Logged In: YES 
user_id=240225
Originator: YES

This is no exactly a great patch, and doesn't fix the base problem, but it
provides a consistent way to get all the meaningfull columns for a user.

The patch adds a function getColumns() to the sqlmeta object (and the
inheritable version), that allways get all the columns for a class
(including parent classes), excluding for the 'childName' column but
including the 'id' column.

This patch makes asDict() function use getColumns(), so there is no need
to override it in the inheritable sqlmeta class. This makes asDict() to
work properly on inheritable sqlobjects, avoiding the "AttributeError:
'SomeSQLObject' object has no attribute '_SO_val_childName'" error.
File Added: sqlobject.r2871.getColumns.patch

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-28 08:15

Message:
Logged In: YES 
user_id=4799
Originator: NO

Reopened; see bug 1665328 for details. Now waiting for a patch...

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 10:22

Message:
Logged In: YES 
user_id=240225
Originator: YES

Because it doesn't behave like a real column (1665328 is an example, a
regular column is inherited to all it's descendant, and the "None" behavior
is another example too) and it's not user data.

But I understand you don't see a great advantage on fixing it, i'll try to
work on it when I have some time if you agree something is wrong and are
interested in patches for this... (and don't want to work on a patch that
it will not be accepted).

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-23 09:35

Message:
Logged In: YES 
user_id=4799
Originator: NO

Why is it a bug? It works as advertised. It is a real column, and it
presents in .columns.

In any case it would be so hard to fix, and fixing it gives so little
advantage - I am not going to work on it. But I can test a patch if one
appears.

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

Comment By: Leandro Lucarella (llucax)
Date: 2007-02-23 09:08

Message:
Logged In: YES 
user_id=240225
Originator: YES

Ok, it should be hard to fix, but don't you agree it's a bug? Shouldn't be
emulated like the "id" column? It's not user data.

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

Comment By: Oleg Broytmann (phd)
Date: 2007-02-22 16:41

Message:
Logged In: YES 
user_id=4799
Originator: NO

SQLObject emulates "id" columns. Unlike that fictional column childName is
a real column. There is no way to remove it from .columns.

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

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

[SQL-CVS] [ sqlobject-Bugs-1775552 ] Escaping Single Quotes in Postgres

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

Bugs item #1775552, was opened at 2007-08-16 19:38
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1775552&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: Postgres
Group: SQLObject release (specify)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: fuchsd (fuchsd)
>Assigned to: Oleg Broytmann (phd)
Summary: Escaping Single Quotes in Postgres

Initial Comment:
Using Postgres 8.3, SQLObject-0-8.1, and psycopg2 2.0.5.1, the following code breaks:

from sqlobject import *

sqlhub.processConnection = connectionForURI('<some postgres DSN>')
class Foo(SQLObject):
    entry = StringCol()
    
Foo.createTable()
f = Foo(entry="Here's an entry")

With this error:
psycopg2.ProgrammingError: syntax error at or near "s"
LINE 1: INSERT INTO bar (id, entry) VALUES (1, 'Here\'s an entry')

Our Postgres server does not allow using a backslash to escape single quotes (this could potentially allow a SQL injection attack: http://www.postgresql.org/docs/8.2/static/runtime-config-compatible.html),
it only allows using another single quote (I'm not sure if we configured it to now allow escaping single quotes with backslashes, or if Postgres defaults to this behavior after a certain version).

This escaping is being done in StringLIkeConverter method at line 104 in converters.py .

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

>Comment By: Oleg Broytmann (phd)
Date: 2007-08-16 19:51

Message:
Logged In: YES 
user_id=4799
Originator: NO

This was fixed in SQLObject 0.7.8, 0.8.5 and 0.9.1. See
http://sqlobject.org/News.html#sqlobject-0-7-8

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

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

[SQL-CVS] [ sqlobject-Bugs-1775552 ] Escaping Single Quotes in Postgres

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

Bugs item #1775552, was opened at 2007-08-16 10:38
Message generated for change (Settings changed) made by fuchsd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1775552&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: Postgres
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: fuchsd (fuchsd)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Escaping Single Quotes in Postgres

Initial Comment:
Using Postgres 8.3, SQLObject-0-8.1, and psycopg2 2.0.5.1, the following code breaks:

from sqlobject import *

sqlhub.processConnection = connectionForURI('<some postgres DSN>')
class Foo(SQLObject):
    entry = StringCol()
    
Foo.createTable()
f = Foo(entry="Here's an entry")

With this error:
psycopg2.ProgrammingError: syntax error at or near "s"
LINE 1: INSERT INTO bar (id, entry) VALUES (1, 'Here\'s an entry')

Our Postgres server does not allow using a backslash to escape single quotes (this could potentially allow a SQL injection attack: http://www.postgresql.org/docs/8.2/static/runtime-config-compatible.html),
it only allows using another single quote (I'm not sure if we configured it to now allow escaping single quotes with backslashes, or if Postgres defaults to this behavior after a certain version).

This escaping is being done in StringLIkeConverter method at line 104 in converters.py .

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

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

[SQL-CVS] [ sqlobject-Bugs-1775552 ] Escaping Single Quotes

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

Bugs item #1775552, was opened at 2007-08-16 10:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1775552&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: Postgres
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: fuchsd (fuchsd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Escaping Single Quotes

Initial Comment:
Using Postgres 8.3, SQLObject-0-8.1, and psycopg2 2.0.5.1, the following code breaks:

from sqlobject import *

sqlhub.processConnection = connectionForURI('<some postgres DSN>')
class Foo(SQLObject):
    entry = StringCol()
    
Foo.createTable()
f = Foo(entry="Here's an entry")

With this error:
psycopg2.ProgrammingError: syntax error at or near "s"
LINE 1: INSERT INTO bar (id, entry) VALUES (1, 'Here\'s an entry')

Our Postgres server does not allow using a backslash to escape single quotes (this could potentially allow a SQL injection attack: http://www.postgresql.org/docs/8.2/static/runtime-config-compatible.html),
it only allows using another single quote (I'm not sure if we configured it to now allow escaping single quotes with backslashes, or if Postgres defaults to this behavior after a certain version).

This escaping is being done in StringLIkeConverter method at line 104 in converters.py .

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

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

[SQL-CVS] [ sqlobject-Bugs-1720866 ] SQLObject 0.9: Unicode interaction problems with MySQLDb

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

Bugs item #1720866, was opened at 2007-05-17 21:19
Message generated for change (Settings changed) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1720866&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: SQLObject 0.9: Unicode interaction problems with MySQLDb

Initial Comment:
E-mail: elv...@gm...

After upgrading to TurboGears 1.0.2.2, SQLObject 0.9 and MySQLdb 1.2.2 final, the Unicode problem still remains. 

Changing line 32 of sqlobject/mysql/mysqlconnection.py, from 

        need_unicode = True

to

        need_unicode = False

solves the problem, as it used to solve in older versions of TurboGears/SQLObject. Maybe it is a bug of MySQLdb, but the code I patched already seems to be a workaround :)

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/CherryPy-2.2.1-py2.5.egg/cherrypy/_cphttptools.py", line 105, in _run
    self.main()
  File "/usr/lib/python2.5/site-packages/CherryPy-2.2.1-py2.5.egg/cherrypy/_cphttptools.py", line 254, in main
    body = page_handler(*virtual_path, **self.params)
  File "<string>", line 3, in fetch
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/controllers.py", line 336, in expose
    *args, **kw)
  File "<string>", line 5, in run_with_transaction
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/database.py", line 303, in so_rwt
    retval = func(*args, **kw)
  File "<string>", line 5, in _expose
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/controllers.py", line 351, in <lambda>
    mapping, fragment, args, kw)))
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/controllers.py", line 378, in _execute_func
    output = errorhandling.try_call(func, *args, **kw)
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/errorhandling.py", line 73, in try_call
    return func(self, *args, **kw)
  File "<string>", line 3, in fetch
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/controllers.py", line 173, in validate
    return errorhandling.run_with_errors(errors, func, *args, **kw)
  File "/usr/lib/python2.5/site-packages/TurboGears-1.0.2.2-py2.5.egg/turbogears/errorhandling.py", line 113, in run_with_errors
    return func(self, *args, **kw)
  File "/home/epx/luca/luca/sys_users.py", line 191, in fetch
    return self.base_fetch(id)
  File "/home/epx/luca/luca/simple_table.py", line 395, in base_fetch
    grant.done(self.row_name(row))
  File "/home/epx/luca/luca/mylib.py", line 69, in done
    self._write()
  File "/home/epx/luca/luca/mylib.py", line 38, in _write
    user=current.user, err=self.logerr)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/declarative.py", line 94, in _wrapper
    return fn(self, *args, **kwargs)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/main.py", line 1214, in __init__
    self._create(id, **kw)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/main.py", line 1245, in _create
    self._SO_finishCreate(id)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/main.py", line 1269, in _SO_finishCreate
    id, names, values)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/dbconnection.py", line 849, in queryInsertID
    self._connection, soInstance, id, names, values)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/mysql/mysqlconnection.py", line 156, in _queryInsertID
    self._executeRetry(conn, c, q)
  File "/usr/lib/python2.5/site-packages/SQLObject-0.9.0-py2.5.egg/sqlobject/mysql/mysqlconnection.py", line 113, in _executeRetry
    query = unicode(query, self.encoding)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 90: ordinal not in range(128)


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

Comment By: Oleg Broytmann (phd)
Date: 2007-07-20 12:41

Message:
Logged In: YES 
user_id=4799
Originator: NO

Does "charset=latin1" or "charset=utf-8" in your DB URI help?

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

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

[SQL-CVS] Dont be afraid of travel by plane this summer time

[goddart o. <sa...@tw...>]

Salut

This med calms down and relieves overexcitement. It also heals epilepsy and acute alcohol withdrawals. 
Hurry up! Now you can get it almost zoom! If you suffer from epilepsy attacks or from anxiety, or you need to 
heal alcoholic withdrawal or muscle spasms this pill will help you. Only now you can buy it for the special sales price!

Hit it here:
http://orux.buyrxshop.com/

See you later, alligator

[SQL-CVS] [ sqlobject-Bugs-1768433 ] Versioning broken in 0.9.1

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

Bugs item #1768433, was opened at 2007-08-06 14:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1768433&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: None
Group: SQLObject release (specify)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: azav (azav)
Assigned to: Nobody/Anonymous (nobody)
Summary: Versioning broken in 0.9.1

Initial Comment:
The versions table uses the same constraints as the original table, so having for instance a unique column in a table will raise a DuplicateEntryError when a second version with the same name is created.

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

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