sqlobject-cvs — CVS notification

[SQL-CVS] [ sqlobject-Patches-1338764 ] Fix for bug #1152199

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

Patches item #1338764, was opened at 2005-10-26 23:05
Message generated for change (Settings changed) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1338764&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cody Casterline (codyc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for bug #1152199

Initial Comment:
This fixed bug #1152199 by moving the assignment to
_SO_createValues before "extra" (_set_*) functions are
called to override defaults. 



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

Comment By: Oleg Broytmann (phd)
Date: 2005-10-28 19:58

Message:
Logged In: YES 
user_id=4799

The patch breaks test_decimal.py:

>       OperationalError: table decimal_table has 2 columns
but 1 values were supplied

By itself it is not a big deal, but it raises suspicions the
entire approach is too quick and too simple.

On the next try please run the entire test suite on at least
two databases; MySQL + SQLIte or Postgres + SQLite would be
the best.

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

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

[SQL-CVS] [ sqlobject-Bugs-1152199 ] "default" options override explicit attribute set

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

Bugs item #1152199, was opened at 2005-02-26 07:12
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1152199&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 from repository
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jamie Wilkinson (jaq37h)
Assigned to: Nobody/Anonymous (nobody)
Summary: "default" options override explicit attribute set

Initial Comment:
I traced this behaviour to the patch at revision 425 in
the repository; at rev 422 it works, and at 425 it doesn't.

My object gets its 'location' attribute set, and the
function _set_location reads the file at that location
and sets a few other attributes within that function.

The behaviour I'm seeing is that these attributes are
being set during the function, but when the object is
referenced later, the default value (as specified when
the column is defined) is returned.

There's a short example attached, that's slightly
contrived to demonstrate the structure of the object,
but runs here.  The output of such a program at rev 425
is None and at 422 is "a string"


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

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

Message:
Logged In: YES 
user_id=4799

The test.py works now with SQLObject 0.7 so I consider the
bug resolved even without the patch 1338764.

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

Comment By: Cody Casterline (codyc)
Date: 2005-10-26 03:47

Message:
Logged In: YES 
user_id=1367914

I've confirmed this bug, and it looks to be caused by the
order of operations in SQLObject.set(self, **kw).

_create() passes default values to set() in **kw.   

set() sets "plainSetter" columns.
set() sets "extra" (_set_*) columns.  
THEN set() does:
self._SO_createValues.update(kw)
... overwriting all of the calculated values just set in the
"extra" columns  block.

I fixed this on my end by removing the dict.update(), and
placing 
self._SO_createValues[name] = dbValue;  in the "plainSetter"
block.  

I haven't submitted it as patch because I'm not sure if this
breaks anything else.  Maybe someone more familiar with the
code will know. :) 

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

Comment By: Oleg Broytmann (phd)
Date: 2005-08-10 17:22

Message:
Logged In: YES 
user_id=4799

You've touched a known problem with setters. Avoid setting
setters' values in constructor. Instead update them after
the objecthas ben created:

t = test(location="")
t.location="some/path"

Now your program works.

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

Comment By: Jamie Wilkinson (jaq37h)
Date: 2005-06-22 10:51

Message:
Logged In: YES 
user_id=440958

Ok, I hunted down my test code and I've reattached it, and
this time I'm sure I've attached it properly :-)

I've modified it a bit too, it'll print out the result of
the test.

I called it like so:

PYTHONPATH=.:SQLObject python test.py

with a fresh svn checkout, and again with a checkout at
revision 421.


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

Comment By: Oleg Broytmann (phd)
Date: 2005-03-01 16:42

Message:
Logged In: YES 
user_id=4799

Please reattach the test. And don't forget to mark the
"Check to Upload and Attach a File" checkbox! (-:

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

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

[SQL-CVS] [ sqlobject-Bugs-1426574 ] Database passwords with '@' don't parse correctly.

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

Bugs item #1426574, was opened at 2006-02-07 12:43
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1426574&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: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Database passwords with '@' don't parse correctly.

Initial Comment:
As the title says, if your database password contains
an '@' character, then the connection string is parsed
incorrectly. To remidy this, I've used host.rfind('@')
instead of host.find('@'). A patch for this would look
something like (I hope the indentation works):

 dbconnection.py.ORIG dbconnection.py
94,99c94,102
<         if host and host.find('@') != -1:
<             user, host = host.split('@', 1)
<             if user.find(':') != -1:
<                 user, password = user.split(':', 1)
<             else:
<                 password = None
---
>         if host:
>           at = host.rfind('@')
>           if at != -1:
>               user = host[:at]
>               host = host[at+1:]
>               if user.find(':') != -1:
>                   user, password = user.split(':', 1)
>               else:
>                   password = None



gk...@gm...

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-02-07 12:45

Message:
Logged In: NO 

Doesn't look like the indentation worked, but it should be
easy to see that rather than using the split function, use
the reverse find() to split the string.

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

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

[SQL-CVS] [ sqlobject-Bugs-1426574 ] Database passwords with '@' don't parse correctly.

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

Bugs item #1426574, was opened at 2006-02-07 12:43
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=1426574&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: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Database passwords with '@' don't parse correctly.

Initial Comment:
As the title says, if your database password contains
an '@' character, then the connection string is parsed
incorrectly. To remidy this, I've used host.rfind('@')
instead of host.find('@'). A patch for this would look
something like (I hope the indentation works):

 dbconnection.py.ORIG dbconnection.py
94,99c94,102
<         if host and host.find('@') != -1:
<             user, host = host.split('@', 1)
<             if user.find(':') != -1:
<                 user, password = user.split(':', 1)
<             else:
<                 password = None
---
>         if host:
>           at = host.rfind('@')
>           if at != -1:
>               user = host[:at]
>               host = host[at+1:]
>               if user.find(':') != -1:
>                   user, password = user.split(':', 1)
>               else:
>                   password = None



gk...@gm...

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

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

[SQL-CVS] [ sqlobject-Patches-1385854 ] Fix myql support for foreign keys

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

Patches item #1385854, was opened at 2005-12-20 06:37
Message generated for change (Comment added) made by smurf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1385854&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: None
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix myql support for foreign keys

Initial Comment:
This change restores proper support for foreign keys
when using the mysql backend.

(It does not force tables to InnoDB.)

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

>Comment By: Matthias Urlichs (smurf)
Date: 2006-02-07 19:59

Message:
Logged In: YES 
user_id=10327

sorry about the missing patch. Attached now.

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

Comment By: Oleg Broytmann (phd)
Date: 2006-01-11 17:27

Message:
Logged In: YES 
user_id=4799

What change?! You've forgotten to check the checkbox before
uploading a file! ;)

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

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

[SQL-CVS] r1583 - in home/phd/SQLObject/paramstyles/sqlobject: . tests

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

Author: phd
Date: 2006-02-07 09:30:50 -0700 (Tue, 07 Feb 2006)
New Revision: 1583

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/cache.py
   home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py
   home/phd/SQLObject/paramstyles/sqlobject/tests/test_transactions.py
Log:
Merged patches from the revisions 1580:1582 from the trunk: applied the patch 1370278: synchronize main connection cache during transaction commit.

Modified: home/phd/SQLObject/paramstyles/sqlobject/cache.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/cache.py	2006-02-07 16:29:27 UTC (rev 1582)
+++ home/phd/SQLObject/paramstyles/sqlobject/cache.py	2006-02-07 16:30:50 UTC (rev 1583)
@@ -316,8 +316,11 @@
             self.caches[cls.__name__].clear()
 
     def tryGet(self, id, cls):
+        return self.tryGetByName(id, cls.__name__)
+
+    def tryGetByName(self, id, clsname):
         try:
-            return self.caches[cls.__name__].tryGet(id)
+            return self.caches[clsname].tryGet(id)
         except KeyError:
             return None
 
@@ -330,6 +333,9 @@
     def allSubCaches(self):
         return self.caches.values()
 
+    def allSubCachesByClassNames(self):
+        return self.caches
+
     def weakrefAll(self, cls=None):
         """
         Move all objects in the cls (or if not given, then in all

Modified: home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py	2006-02-07 16:29:27 UTC (rev 1582)
+++ home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py	2006-02-07 16:30:50 UTC (rev 1583)
@@ -801,6 +801,7 @@
         self._connection = dbConnection.getConnection()
         self._dbConnection._setAutoCommit(self._connection, 0)
         self.cache = CacheSet(cache=dbConnection.doCache)
+        self._deletedCache = {}
 
     def assertActive(self):
         assert not self._obsolete, "This transaction has already gone through ROLLBACK; begin another transaction"
@@ -832,6 +833,13 @@
         return iter(list(select.IterationClass(self, self._connection,
                                    select, keepConnection=True)))
 
+    def _SO_delete(self, inst):
+        cls = inst.__class__.__name__
+        if not self._deletedCache.has_key(cls):
+            self._deletedCache[cls] = []
+        self._deletedCache[cls].append(inst.id)
+        return self._dbConnection._SO_delete(inst)
+
     def commit(self, close=False):
         if self._obsolete:
             # @@: is it okay to get extraneous commits?
@@ -841,6 +849,13 @@
         self._connection.commit()
         if close:
             self._makeObsolete()
+        subCaches = [(sub[0], sub[1].allIDs()) for sub in self.cache.allSubCachesByClassNames().items()]
+        subCaches.extend([(x[0], x[1]) for x in self._deletedCache.items()])
+        for cls, ids in subCaches:
+            for id in ids:
+                inst = self._dbConnection.cache.tryGetByName(id, cls)
+                if inst is not None:
+                    inst.expire()
 
     def rollback(self):
         if self._obsolete:
@@ -884,6 +899,7 @@
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
+        self._deletedCache = {}
 
     def begin(self):
         # @@: Should we do this, or should begin() be a no-op when we're

Modified: home/phd/SQLObject/paramstyles/sqlobject/tests/test_transactions.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/tests/test_transactions.py	2006-02-07 16:29:27 UTC (rev 1582)
+++ home/phd/SQLObject/paramstyles/sqlobject/tests/test_transactions.py	2006-02-07 16:30:50 UTC (rev 1583)
@@ -36,3 +36,18 @@
     finally:
         TestSOTrans._connection.autoCommit = True
 
+def test_transaction_commit_sync():
+    if not supports('transactions'):
+        return
+    setupClass(TestSOTrans)
+    trans = TestSOTrans._connection.transaction()
+    try:
+        TestSOTrans(name='bob')
+        bOut = TestSOTrans.byName('bob')
+        bIn = TestSOTrans.byName('bob', connection=trans)
+        bIn.name = 'robert'
+        assert bOut.name == 'bob'
+        trans.commit()
+        assert bOut.name == 'robert'
+    finally:
+        TestSOTrans._connection.autoCommit = True

[SQL-CVS] r1585 - SQLObject/branches/0.7-bugfix/sqlobject/sqlite

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

Author: phd
Date: 2006-02-07 10:08:42 -0700 (Tue, 07 Feb 2006)
New Revision: 1585

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/sqlite/sqliteconnection.py
Log:
Applied the patch 1380405: enable check_same_thread option in SQLiteConnection.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/sqlite/sqliteconnection.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/sqlite/sqliteconnection.py	2006-02-07 17:08:08 UTC (rev 1584)
+++ SQLObject/branches/0.7-bugfix/sqlobject/sqlite/sqliteconnection.py	2006-02-07 17:08:42 UTC (rev 1585)
@@ -29,7 +29,6 @@
             if not using_sqlite2:
                 raise ValueError(
                     "You must use sqlite2 to use in-memory databases")
-            #kw.setdefault('check_same_thread', False)
         # connection options
         opts = {}
         if using_sqlite2:
@@ -63,6 +62,8 @@
                 opts['mode'] = int(popKey(kw, 'mode'), 0)
         if 'timeout' in kw:
             opts['timeout'] = float(popKey(kw, 'timeout'))
+        if 'check_same_thread' in kw:
+            opts["check_same_thread"] = bool(popKey(kw, 'check_same_thread'))
         # use only one connection for sqlite - supports multiple)
         # cursors per connection
         self._connOptions = opts

[SQL-CVS] r1582 - in SQLObject/branches/0.7-bugfix/sqlobject: . tests

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

Author: phd
Date: 2006-02-07 09:29:27 -0700 (Tue, 07 Feb 2006)
New Revision: 1582

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/cache.py
   SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py
   SQLObject/branches/0.7-bugfix/sqlobject/tests/test_transactions.py
Log:
Applied the patch 1370278: synchronize main connection cache during transaction commit.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/cache.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/cache.py	2006-02-07 16:26:19 UTC (rev 1581)
+++ SQLObject/branches/0.7-bugfix/sqlobject/cache.py	2006-02-07 16:29:27 UTC (rev 1582)
@@ -292,8 +292,11 @@
             self.caches[cls.__name__].clear()
 
     def tryGet(self, id, cls):
+        return self.tryGetByName(id, cls.__name__)
+
+    def tryGetByName(self, id, clsname):
         try:
-            return self.caches[cls.__name__].tryGet(id)
+            return self.caches[clsname].tryGet(id)
         except KeyError:
             return None
 
@@ -305,3 +308,6 @@
 
     def allSubCaches(self):
         return self.caches.values()
+
+    def allSubCachesByClassNames(self):
+        return self.caches

Modified: SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py	2006-02-07 16:26:19 UTC (rev 1581)
+++ SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py	2006-02-07 16:29:27 UTC (rev 1582)
@@ -736,6 +736,7 @@
         self._connection = dbConnection.getConnection()
         self._dbConnection._setAutoCommit(self._connection, 0)
         self.cache = CacheSet(cache=dbConnection.doCache)
+        self._deletedCache = {}
 
     def assertActive(self):
         assert not self._obsolete, "This transaction has already gone through ROLLBACK; begin another transaction"
@@ -767,6 +768,13 @@
         return iter(list(select.IterationClass(self, self._connection,
                                    select, keepConnection=True)))
 
+    def _SO_delete(self, inst):
+        cls = inst.__class__.__name__
+        if not self._deletedCache.has_key(cls):
+            self._deletedCache[cls] = []
+        self._deletedCache[cls].append(inst.id)
+        return self._dbConnection._SO_delete(inst)
+
     def commit(self):
         if self._obsolete:
             # @@: is it okay to get extraneous commits?
@@ -774,6 +782,13 @@
         if self._dbConnection.debug:
             self._dbConnection.printDebug(self._connection, '', 'COMMIT')
         self._connection.commit()
+        subCaches = [(sub[0], sub[1].allIDs()) for sub in self.cache.allSubCachesByClassNames().items()]
+        subCaches.extend([(x[0], x[1]) for x in self._deletedCache.items()])
+        for cls, ids in subCaches:
+            for id in ids:
+                inst = self._dbConnection.cache.tryGetByName(id, cls)
+                if inst is not None:
+                    inst.expire()
 
     def rollback(self):
         if self._obsolete:
@@ -817,6 +832,7 @@
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
+        self._deletedCache = {}
 
     def begin(self):
         # @@: Should we do this, or should begin() be a no-op when we're

Modified: SQLObject/branches/0.7-bugfix/sqlobject/tests/test_transactions.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/tests/test_transactions.py	2006-02-07 16:26:19 UTC (rev 1581)
+++ SQLObject/branches/0.7-bugfix/sqlobject/tests/test_transactions.py	2006-02-07 16:29:27 UTC (rev 1582)
@@ -36,3 +36,18 @@
     finally:
         TestSOTrans._connection.autoCommit = True
 
+def test_transaction_commit_sync():
+    if not supports('transactions'):
+        return
+    setupClass(TestSOTrans)
+    trans = TestSOTrans._connection.transaction()
+    try:
+        TestSOTrans(name='bob')
+        bOut = TestSOTrans.byName('bob')
+        bIn = TestSOTrans.byName('bob', connection=trans)
+        bIn.name = 'robert'
+        assert bOut.name == 'bob'
+        trans.commit()
+        assert bOut.name == 'robert'
+    finally:
+        TestSOTrans._connection.autoCommit = True

[SQL-CVS] r1586 - home/phd/SQLObject/paramstyles/sqlobject/sqlite

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

Author: phd
Date: 2006-02-07 10:13:06 -0700 (Tue, 07 Feb 2006)
New Revision: 1586

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/sqlite/sqliteconnection.py
Log:
Merged patches from the revisions 1585:1585 from the trunk: applied the patch 1380405: enable check_same_thread option in SQLiteConnection.

Modified: home/phd/SQLObject/paramstyles/sqlobject/sqlite/sqliteconnection.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/sqlite/sqliteconnection.py	2006-02-07 17:08:42 UTC (rev 1585)
+++ home/phd/SQLObject/paramstyles/sqlobject/sqlite/sqliteconnection.py	2006-02-07 17:13:06 UTC (rev 1586)
@@ -29,7 +29,6 @@
             if not using_sqlite2:
                 raise ValueError(
                     "You must use sqlite2 to use in-memory databases")
-            #kw.setdefault('check_same_thread', False)
         # connection options
         opts = {}
         if using_sqlite2:
@@ -63,6 +62,8 @@
                 opts['mode'] = int(popKey(kw, 'mode'), 0)
         if 'timeout' in kw:
             opts['timeout'] = float(popKey(kw, 'timeout'))
+        if 'check_same_thread' in kw:
+            opts["check_same_thread"] = bool(popKey(kw, 'check_same_thread'))
         # use only one connection for sqlite - supports multiple)
         # cursors per connection
         self._connOptions = opts

[SQL-CVS] r1584 - SQLObject/trunk/sqlobject/sqlite

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

Author: phd
Date: 2006-02-07 10:08:08 -0700 (Tue, 07 Feb 2006)
New Revision: 1584

Modified:
   SQLObject/trunk/sqlobject/sqlite/sqliteconnection.py
Log:
Applied the patch 1380405: enable check_same_thread option in SQLiteConnection.


Modified: SQLObject/trunk/sqlobject/sqlite/sqliteconnection.py
===================================================================
--- SQLObject/trunk/sqlobject/sqlite/sqliteconnection.py	2006-02-07 16:30:50 UTC (rev 1583)
+++ SQLObject/trunk/sqlobject/sqlite/sqliteconnection.py	2006-02-07 17:08:08 UTC (rev 1584)
@@ -29,7 +29,6 @@
             if not using_sqlite2:
                 raise ValueError(
                     "You must use sqlite2 to use in-memory databases")
-            #kw.setdefault('check_same_thread', False)
         # connection options
         opts = {}
         if using_sqlite2:
@@ -63,6 +62,8 @@
                 opts['mode'] = int(popKey(kw, 'mode'), 0)
         if 'timeout' in kw:
             opts['timeout'] = float(popKey(kw, 'timeout'))
+        if 'check_same_thread' in kw:
+            opts["check_same_thread"] = bool(popKey(kw, 'check_same_thread'))
         # use only one connection for sqlite - supports multiple)
         # cursors per connection
         self._connOptions = opts

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

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

Author: phd
Date: 2006-02-07 09:26:19 -0700 (Tue, 07 Feb 2006)
New Revision: 1581

Modified:
   SQLObject/trunk/sqlobject/cache.py
   SQLObject/trunk/sqlobject/dbconnection.py
   SQLObject/trunk/sqlobject/tests/test_transactions.py
Log:
Applied the patch 1370278: synchronize main connection cache during transaction commit.


Modified: SQLObject/trunk/sqlobject/cache.py
===================================================================
--- SQLObject/trunk/sqlobject/cache.py	2006-02-06 19:41:36 UTC (rev 1580)
+++ SQLObject/trunk/sqlobject/cache.py	2006-02-07 16:26:19 UTC (rev 1581)
@@ -316,8 +316,11 @@
             self.caches[cls.__name__].clear()
 
     def tryGet(self, id, cls):
+        return self.tryGetByName(id, cls.__name__)
+
+    def tryGetByName(self, id, clsname):
         try:
-            return self.caches[cls.__name__].tryGet(id)
+            return self.caches[clsname].tryGet(id)
         except KeyError:
             return None
 
@@ -330,6 +333,9 @@
     def allSubCaches(self):
         return self.caches.values()
 
+    def allSubCachesByClassNames(self):
+        return self.caches
+
     def weakrefAll(self, cls=None):
         """
         Move all objects in the cls (or if not given, then in all

Modified: SQLObject/trunk/sqlobject/dbconnection.py
===================================================================
--- SQLObject/trunk/sqlobject/dbconnection.py	2006-02-06 19:41:36 UTC (rev 1580)
+++ SQLObject/trunk/sqlobject/dbconnection.py	2006-02-07 16:26:19 UTC (rev 1581)
@@ -788,6 +788,7 @@
         self._connection = dbConnection.getConnection()
         self._dbConnection._setAutoCommit(self._connection, 0)
         self.cache = CacheSet(cache=dbConnection.doCache)
+        self._deletedCache = {}
 
     def assertActive(self):
         assert not self._obsolete, "This transaction has already gone through ROLLBACK; begin another transaction"
@@ -819,6 +820,13 @@
         return iter(list(select.IterationClass(self, self._connection,
                                    select, keepConnection=True)))
 
+    def _SO_delete(self, inst):
+        cls = inst.__class__.__name__
+        if not self._deletedCache.has_key(cls):
+            self._deletedCache[cls] = []
+        self._deletedCache[cls].append(inst.id)
+        return self._dbConnection._SO_delete(inst)
+
     def commit(self, close=False):
         if self._obsolete:
             # @@: is it okay to get extraneous commits?
@@ -828,6 +836,13 @@
         self._connection.commit()
         if close:
             self._makeObsolete()
+        subCaches = [(sub[0], sub[1].allIDs()) for sub in self.cache.allSubCachesByClassNames().items()]
+        subCaches.extend([(x[0], x[1]) for x in self._deletedCache.items()])
+        for cls, ids in subCaches:
+            for id in ids:
+                inst = self._dbConnection.cache.tryGetByName(id, cls)
+                if inst is not None:
+                    inst.expire()
 
     def rollback(self):
         if self._obsolete:
@@ -871,6 +886,7 @@
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
+        self._deletedCache = {}
 
     def begin(self):
         # @@: Should we do this, or should begin() be a no-op when we're

Modified: SQLObject/trunk/sqlobject/tests/test_transactions.py
===================================================================
--- SQLObject/trunk/sqlobject/tests/test_transactions.py	2006-02-06 19:41:36 UTC (rev 1580)
+++ SQLObject/trunk/sqlobject/tests/test_transactions.py	2006-02-07 16:26:19 UTC (rev 1581)
@@ -36,3 +36,18 @@
     finally:
         TestSOTrans._connection.autoCommit = True
 
+def test_transaction_commit_sync():
+    if not supports('transactions'):
+        return
+    setupClass(TestSOTrans)
+    trans = TestSOTrans._connection.transaction()
+    try:
+        TestSOTrans(name='bob')
+        bOut = TestSOTrans.byName('bob')
+        bIn = TestSOTrans.byName('bob', connection=trans)
+        bIn.name = 'robert'
+        assert bOut.name == 'bob'
+        trans.commit()
+        assert bOut.name == 'robert'
+    finally:
+        TestSOTrans._connection.autoCommit = True

[SQL-CVS] [ sqlobject-Patches-1385854 ] Fix myql support for foreign keys

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

Patches item #1385854, was opened at 2005-12-20 08:37
Message generated for change (Settings changed) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1385854&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix myql support for foreign keys

Initial Comment:
This change restores proper support for foreign keys
when using the mysql backend.

(It does not force tables to InnoDB.)

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

Comment By: Oleg Broytmann (phd)
Date: 2006-01-11 19:27

Message:
Logged In: YES 
user_id=4799

What change?! You've forgotten to check the checkbox before
uploading a file! ;)

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

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

[SQL-CVS] [ sqlobject-Patches-1380405 ] enable check_same_thread option in SQLiteConnection

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

Patches item #1380405, was opened at 2005-12-14 15:51
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1380405&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: I*igo Serna (inigoserna)
>Assigned to: Oleg Broytmann (phd)
Summary: enable check_same_thread option in SQLiteConnection

Initial Comment:
Hi there,

For a project I'm writing using CherryPy + SQLObject +
sqlite3 I need to pass "enable_check_same_thread =
False" option to pysqlite2 in SQLiteConnection, but
SQLObject 0.7rc1 doesn't allow it, so I've written this
simple patch.

I know this is an evil option, but I *really* need it
in my project (cherrypy app is exposed to apache using
mpcp-1.2) or it's the only solution I've found.

Default remains safe enable_check_same_thread = True
option.

Patch is against SQLObject 0.7rc1.

Iñigo

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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-07 20:09

Message:
Logged In: YES 
user_id=4799

Applied at the revision 1585 to the trunk. Thank you!

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

Comment By: Oleg Broytmann (phd)
Date: 2006-01-11 19:36

Message:
Logged In: YES 
user_id=4799

Please instead of extending __init__() args put
check_same_thread into kw, similar to 'encoding', 'mode' and
'timeout'.

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

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

[SQL-CVS] [ sqlobject-Patches-1370278 ] Synchronize main connection cache during transaction commit

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

Patches item #1370278, was opened at 2005-11-30 21:32
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1370278&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Luke Opperman (luke_opperman)
Assigned to: Oleg Broytmann (phd)
Summary: Synchronize main connection cache during transaction commit

Initial Comment:
See this thread:

http://pythonpaste.org/archives/message/20051129.172427.0ec7941f.en.html

And this earlier one:

http://sourceforge.net/mailarchive/message.php?msg_id=11354123

This fix deals with something not mentioned in the
latter message, objects deleted as part of the transaction.


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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-07 19:31

Message:
Logged In: YES 
user_id=4799

Applied to the trunk at the revision 1581 and 1582 to the
0.7-branch. Thank you!

PS. It seems there were many bugs in PySQLite - after I have
upgraded to SQLite 3.3.3 and PySQLite 1.1.7/2.1.3 your patch
(and some other patches that had failed) passes all tests.

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

Comment By: Oleg Broytmann (phd)
Date: 2006-01-03 14:17

Message:
Logged In: YES 
user_id=4799

Error with PySQLite 1 and 2 in test_transactions.py:

Exception _sqlite.ProgrammingError:
<_sqlite.ProgrammingError instance at 0xb7729d0c> in <bound
method Transaction.__del__ of
<sqlobject.dbconnection.Transaction object at 0xb7731b4c>>
ignored

Exception pysqlite2.dbapi2.ProgrammingError: 'Cannot operate
on a closed database.' in <bound method Transaction.__del__
of <sqlobject.dbconnection.Transaction object at
0xb771944c>> ignored

With Postgres the test passed ok.

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

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

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

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

Author: phd
Date: 2006-02-06 12:41:36 -0700 (Mon, 06 Feb 2006)
New Revision: 1580

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py
Log:
Merged patches from the revisions 1577:1578 from the trunk: set and reset autocommit on the low-level connection.

Modified: home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py	2006-02-06 19:41:00 UTC (rev 1579)
+++ home/phd/SQLObject/paramstyles/sqlobject/dbconnection.py	2006-02-06 19:41:36 UTC (rev 1580)
@@ -879,6 +879,8 @@
 
     def _makeObsolete(self):
         self._obsolete = True
+        if self._dbConnection.autoCommit:
+            self._dbConnection._setAutoCommit(self._connection, 1)
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
@@ -889,6 +891,7 @@
         assert self._obsolete, "You cannot begin a new transaction session without rolling back this one"
         self._obsolete = False
         self._connection = self._dbConnection.getConnection()
+        self._dbConnection._setAutoCommit(self._connection, 0)
 
     def __del__(self):
         if self._obsolete:

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

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

Author: phd
Date: 2006-02-06 12:41:00 -0700 (Mon, 06 Feb 2006)
New Revision: 1579

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py
Log:
Set and reset autocommit on the low-level connection.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py	2006-02-06 19:40:21 UTC (rev 1578)
+++ SQLObject/branches/0.7-bugfix/sqlobject/dbconnection.py	2006-02-06 19:41:00 UTC (rev 1579)
@@ -812,6 +812,8 @@
 
     def _makeObsolete(self):
         self._obsolete = True
+        if self._dbConnection.autoCommit:
+            self._dbConnection._setAutoCommit(self._connection, 1)
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
@@ -822,6 +824,7 @@
         assert self._obsolete, "You cannot begin a new transaction session without rolling back this one"
         self._obsolete = False
         self._connection = self._dbConnection.getConnection()
+        self._dbConnection._setAutoCommit(self._connection, 0)
 
     def __del__(self):
         if self._obsolete:

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

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

Author: phd
Date: 2006-02-06 12:40:21 -0700 (Mon, 06 Feb 2006)
New Revision: 1578

Modified:
   SQLObject/trunk/sqlobject/dbconnection.py
Log:
Set and reset autocommit on the low-level connection.


Modified: SQLObject/trunk/sqlobject/dbconnection.py
===================================================================
--- SQLObject/trunk/sqlobject/dbconnection.py	2006-02-06 18:56:55 UTC (rev 1577)
+++ SQLObject/trunk/sqlobject/dbconnection.py	2006-02-06 19:40:21 UTC (rev 1578)
@@ -866,6 +866,8 @@
 
     def _makeObsolete(self):
         self._obsolete = True
+        if self._dbConnection.autoCommit:
+            self._dbConnection._setAutoCommit(self._connection, 1)
         self._dbConnection.releaseConnection(self._connection,
                                              explicit=True)
         self._connection = None
@@ -876,6 +878,7 @@
         assert self._obsolete, "You cannot begin a new transaction session without rolling back this one"
         self._obsolete = False
         self._connection = self._dbConnection.getConnection()
+        self._dbConnection._setAutoCommit(self._connection, 0)
 
     def __del__(self):
         if self._obsolete:

[SQL-CVS] [ sqlobject-Bugs-1424667 ] 'maximum recursion depth exceeded' when __len__ is defined

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

Bugs item #1424667, was opened at 2006-02-05 20:57
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1424667&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: DBM
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Bartel (karlb)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'maximum recursion depth exceeded' when __len__ is defined

Initial Comment:
class BugListEntry(SQLObject):
    bug_list = ForeignKey('BugList')

class BugList(SQLObject):
    entries = MultipleJoin('BugListEntry')
    
    def __len__(self):
        return len(self.entries)

When I'm calling 'BugList()' I get a 'RuntimeError: maximum recursion 
depth exceeded'. Is this a bug in SQLObject, or am I doing something 
wrong?
It works fine when I'm removing the '__len__'  method.

I'm using SQLObject as a part of TurboGears 8.8 with an SQLite database.

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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-06 22:14

Message:
Logged In: YES 
user_id=4799

I cannot reproduce it. The program doesn't raise an
exception. Can you write a complete test program (without
TG) and show the exception it raises? 

BTW, look at the FAQ in the repository:
http://svn.colorstudy.com/SQLObject/docs/FAQ.txt to
understand the reasons why there is no __len__.

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

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

[SQL-CVS] [ sqlobject-Bugs-1424369 ] selectBy doesn't protest invalid columns

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

Bugs item #1424369, was opened at 2006-02-05 07:25
Message generated for change (Settings changed) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1424369&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 from repository
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Garrett Smith (garrett1020)
>Assigned to: Oleg Broytmann (phd)
Summary: selectBy doesn't protest invalid columns

Initial Comment:
I mistakenly used 'ownerId' rather than 'ownerID' in a
selectBy call. Rather than raise an exception, the
SQLObject generated a select with the following where
clause:

WHERE 1 = 1


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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-06 22:05

Message:
Logged In: YES 
user_id=4799

This has been fixed by the patch 1422132:
https://sourceforge.net/tracker/index.php?func=detail&aid=1422132&group_id=74338&atid=540674

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

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

[SQL-CVS] r1577 - home/phd/SQLObject/paramstyles/sqlobject/postgres

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

Author: phd
Date: 2006-02-06 11:56:55 -0700 (Mon, 06 Feb 2006)
New Revision: 1577

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/postgres/pgconnection.py
Log:
Merged patches from the revisions 1574:1575 from the trunk: fixed the bug 1421633.

Modified: home/phd/SQLObject/paramstyles/sqlobject/postgres/pgconnection.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/postgres/pgconnection.py	2006-02-06 18:55:27 UTC (rev 1576)
+++ home/phd/SQLObject/paramstyles/sqlobject/postgres/pgconnection.py	2006-02-06 18:56:55 UTC (rev 1577)
@@ -318,10 +318,7 @@
         # We must close the transaction with a commit so that
         # the CREATE DATABASE can work (which can't be in a transaction):
         cur.execute('COMMIT')
-        # And we can't use template1 since we're connected to template1,
-        # so we use template0.  @@: What's the difference between
-        # these two templates?
-        cur.execute('CREATE DATABASE %s TEMPLATE=template0' % self.db)
+        cur.execute('CREATE DATABASE %s' % self.db)
         cur.close()
         conn.close()
 

[SQL-CVS] [ sqlobject-Bugs-1421633 ] template0 versus template1

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

Bugs item #1421633, was opened at 2006-02-01 19:40
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1421633&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 from repository
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Oleg Broytmann (phd)
Summary: template0 versus template1

Initial Comment:
There's a comment in SQLObject from the repository
about what the difference between template0 and
template1 is. It should not specify the template at
all, it should just use the default one when it runs
CREATE DATABASE.

It is also very naughty to create the database from
template0. First, the postgresql 8.1 docs say template0
is called postgres instead. Second, template1 is the
place for database features the user intends to put in
all new databases (for me, it's pl/sql and postgis
geographic types).

Just connect to template1 or don't specify a database
name to connect to and 'CREATE DATABASE db_name'. It
works fine.

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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-06 21:56

Message:
Logged In: YES 
user_id=4799

Fixed at the revision 1575 in the trunk and 1576 in the
0.7-branch. Thank you!

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

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

[SQL-CVS] r1576 - SQLObject/branches/0.7-bugfix/sqlobject/postgres

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

Author: phd
Date: 2006-02-06 11:55:27 -0700 (Mon, 06 Feb 2006)
New Revision: 1576

Modified:
   SQLObject/branches/0.7-bugfix/sqlobject/postgres/pgconnection.py
Log:
Fixed the bug 1421633.


Modified: SQLObject/branches/0.7-bugfix/sqlobject/postgres/pgconnection.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/postgres/pgconnection.py	2006-02-06 18:54:46 UTC (rev 1575)
+++ SQLObject/branches/0.7-bugfix/sqlobject/postgres/pgconnection.py	2006-02-06 18:55:27 UTC (rev 1576)
@@ -318,10 +318,7 @@
         # We must close the transaction with a commit so that
         # the CREATE DATABASE can work (which can't be in a transaction):
         cur.execute('COMMIT')
-        # And we can't use template1 since we're connected to template1,
-        # so we use template0.  @@: What's the difference between
-        # these two templates?
-        cur.execute('CREATE DATABASE %s TEMPLATE=template0' % self.db)
+        cur.execute('CREATE DATABASE %s' % self.db)
         cur.close()
         conn.close()
 

[SQL-CVS] r1575 - SQLObject/trunk/sqlobject/postgres

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

Author: phd
Date: 2006-02-06 11:54:46 -0700 (Mon, 06 Feb 2006)
New Revision: 1575

Modified:
   SQLObject/trunk/sqlobject/postgres/pgconnection.py
Log:
Fixed the bug 1421633.


Modified: SQLObject/trunk/sqlobject/postgres/pgconnection.py
===================================================================
--- SQLObject/trunk/sqlobject/postgres/pgconnection.py	2006-02-06 18:32:42 UTC (rev 1574)
+++ SQLObject/trunk/sqlobject/postgres/pgconnection.py	2006-02-06 18:54:46 UTC (rev 1575)
@@ -318,10 +318,7 @@
         # We must close the transaction with a commit so that
         # the CREATE DATABASE can work (which can't be in a transaction):
         cur.execute('COMMIT')
-        # And we can't use template1 since we're connected to template1,
-        # so we use template0.  @@: What's the difference between
-        # these two templates?
-        cur.execute('CREATE DATABASE %s TEMPLATE=template0' % self.db)
+        cur.execute('CREATE DATABASE %s' % self.db)
         cur.close()
         conn.close()
 

[SQL-CVS] [ sqlobject-Bugs-1415409 ] sqlmeta's addJoin ignores joinMethodName

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

Bugs item #1415409, was opened at 2006-01-26 16:20
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1415409&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: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlmeta's addJoin ignores joinMethodName 

Initial Comment:
<bug info>
Discovered by Ramon Bastiaans <bas...@sa...>:

In SQLObject 0.7 with Python 2.3 on Debian Linux in
conjuction with Postgres SQL.
</bug info>

1. Started with a dbase .py with something like this;

---
class <existing_table>( SQLObject ):

   .. bla ..
   .. bla ..
   .. bla ..
---
2. then I added:
---
class <new_relation>( SQLObject ):

   .. bla ..
   .. bla ..
---
3. Then I did:

python
from my_dbase import existing_table, new_relation
existing_table.sqlmeta.addJoin( RelatedJoin(
'new_relation', joinMethodName='lookatmynewclass' ) )

4. Then I changed my initial setup to:
---
class <existing_table>( SQLObject ):

   .. bla ..
   .. bla ..
   .. bla ..
   lookatmynewclass = RelatedJoin( 'new_relation' )
---

5. Now when I do:
---
my_object = existing_table.selectBy(
mywhatever='something' )
print dir( my_object )
---

There is a attribute "new_relations" (new class + 's')
instead of (what I expected) "lookatmynewclass".

6. I have worked around this by changing my class
definition to:
---
class <existing_table>( SQLObject ):

   .. bla ..
   .. bla ..
   .. bla ..
   lookatmynewclass = RelatedJoin( 'new_relation',
joinMethodName='lookatmynewclass' )
---


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

>Comment By: Oleg Broytmann (phd)
Date: 2006-02-06 21:35

Message:
Logged In: YES 
user_id=4799

This is a duplicate of the bug 1415402.

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

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

[SQL-CVS] r1574 - SQLObject/branches/0.7-bugfix/docs

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

Author: phd
Date: 2006-02-06 11:32:42 -0700 (Mon, 06 Feb 2006)
New Revision: 1574

Modified:
   SQLObject/branches/0.7-bugfix/docs/FAQ.txt
   SQLObject/branches/0.7-bugfix/docs/SQLObject.txt
Log:
Fixed the bug 1415071. Fixed reST formatting.


Modified: SQLObject/branches/0.7-bugfix/docs/FAQ.txt
===================================================================
--- SQLObject/branches/0.7-bugfix/docs/FAQ.txt	2006-02-06 18:28:58 UTC (rev 1573)
+++ SQLObject/branches/0.7-bugfix/docs/FAQ.txt	2006-02-06 18:32:42 UTC (rev 1574)
@@ -79,11 +79,11 @@
 How can I join a table with itself?
 -----------------------------------
 
-Use Alias from SQLBuilder_.
+Use Alias from SQLBuilder_. See example_.
 
 .. _SQLBuilder: SQLBuilder.html
+.. _example: SQLObject.html#how-can-i-join-a-table-with-itself
 
-
 How Does Inheritance Work?
 --------------------------
 

Modified: SQLObject/branches/0.7-bugfix/docs/SQLObject.txt
===================================================================
--- SQLObject/branches/0.7-bugfix/docs/SQLObject.txt	2006-02-06 18:28:58 UTC (rev 1573)
+++ SQLObject/branches/0.7-bugfix/docs/SQLObject.txt	2006-02-06 18:32:42 UTC (rev 1574)
@@ -407,7 +407,7 @@
     <Address 1 ...>
     >>> p.addresses
     [<Address 1 ...>]
-    
+
 .. note::
   MultipleJoin, as well as RelatedJoin, returns a list of results.
   Would you prefer to get a SelectResults objects, you should use
@@ -478,7 +478,7 @@
 methods add/removesomething may not work as expected. Assuming that
 you are providing the join with the correct joinColumn and otherColumn
 arguments, be aware it's not possibile to insert extra data via such
-methodos, nor will they set any default value.  
+methodos, nor will they set any default value.
 
 Let's have an example: in the previous User/Role system,
 you're creating a UserRole intermediate table, with the two columns
@@ -656,8 +656,8 @@
 
 `table`:
    The name of the table in the database.  This is derived from
-   ``style`` and the class name if no explicit name is given.  If you 
-   don't give a name and haven't defined an alternative ``style``, then 
+   ``style`` and the class name if no explicit name is given.  If you
+   don't give a name and haven't defined an alternative ``style``, then
    the standard `MixedCase` to `mixed_case` translation is performed.
 
 `idName`:
@@ -670,10 +670,10 @@
    is ``int`` by default (all IDs are normalized to integers).
 
 `style`:
-   A style object -- this object allows you to use other algorithms 
+   A style object -- this object allows you to use other algorithms
    for translating between Python attribute and class names, and the
    database's column and table names.  See `Changing the Naming
-   Style`_ for more.  It is an instance of the `IStyle` interface.  
+   Style`_ for more.  It is an instance of the `IStyle` interface.
 
 `lazyUpdate`:
    A boolean (default false).  If true, then setting attributes on
@@ -695,9 +695,9 @@
    If set to `False` then values for attributes from the database
    won't be cached.  So every time you access an attribute in the
    object the database will be queried for a value, i.e., a ``SELECT``
-   will be issued.  If you want to handle concurrent access to the 
-   database from multiple processes then this is probably the way to 
-   do so.  You should also use it with transactions_ (it is not 
+   will be issued.  If you want to handle concurrent access to the
+   database from multiple processes then this is probably the way to
+   do so.  You should also use it with transactions_ (it is not
    implied).
 
 `registry`:
@@ -737,10 +737,10 @@
    attributes are accessed a query will be run.
 
 
-While in previous versions of SQLObject those attributes were defined 
+While in previous versions of SQLObject those attributes were defined
 directly at the class that will map your database data to Python and
 all of them were prefixed with an underscore, now it is suggested that
-you change your code to this new style.  The old way will be removed 
+you change your code to this new style.  The old way will be removed
 when SQLObject 0.8 is out and you'll receive lots of warning messages
 saying that if you're not using the ``sqlmeta`` class you're doing things
 in a deprecated way.
@@ -783,11 +783,11 @@
 SQLObject Class
 ---------------
 
-Besides sqlmeta and columns specifications, there are a number of other 
+Besides sqlmeta and columns specifications, there are a number of other
 special attributes you can set in your class.  Those are listed below but,
 except for the ``_connection`` attribute, all other are superseded by the
 implementation shown before with sqlmeta.  If you use them with SQLObject
-0.7 you'll get warnings about their deprecation and you'll probably have 
+0.7 you'll get warnings about their deprecation and you'll probably have
 to convert your code in future releases, when these are dropped.
 
 `_connection`:
@@ -811,7 +811,7 @@
     from sqlmeta class.
 
 `_cacheValues`:
-    This is old style and works the same way as the `cacheValues` 
+    This is old style and works the same way as the `cacheValues`
     attribute from sqlmeta class.
 
 .. _idName:
@@ -973,7 +973,7 @@
 Undefined attributes
 ~~~~~~~~~~~~~~~~~~~~
 
-There's one more thing  worth telling, because you may something get 
+There's one more thing  worth telling, because you may something get
 strange results when making a typo. SQLObject won't ever complain or
 raise any error when setting a previously undefined attribute; it will
 simply set it, without making any change to the database, i.e: it will
@@ -1075,12 +1075,12 @@
     Base-10, precise number.  Uses the keyword arguments `size` for
     number of digits stored, and `precision` for the number of digits
     after the decimal point.
-	  WARNING: it may happen that DecimalCol values, although correctly
-	  stored in the DB, are returned as floats instead of decimals. 
-	  You should test with your database adapter, and you should try
-	  importing the Decimal type and your DB adapter before importing
-	  SQLObject.
-	  
+    WARNING: it may happen that DecimalCol values, although correctly
+    stored in the DB, are returned as floats instead of decimals.
+    You should test with your database adapter, and you should try
+    importing the Decimal type and your DB adapter before importing
+    SQLObject.
+
 `EnumCol`:
     One of several string values -- give the possible strings as a
     list, with the `enumValues` keyword argument.  MySQL has a native
@@ -1153,7 +1153,7 @@
     into 'product_no_id' in the DB ( product_no is the normal uppercase-
     to-lowercase + underscores SQLO Translation, the added _id is just
     because the column referring to the table is probably a ForeignKey,
-    and SQLO translates foreign keys that way). 
+    and SQLO translates foreign keys that way).
     You should pass that parameter.
 `orderBy`:
     Like the `orderBy`_ argument to `select()`, you can specify
@@ -1190,20 +1190,20 @@
     `removeRole(role)` are created.  The ``Role`` portion of these
     method names can be changed by giving a string value here.
 `createRelatedTable`:
-		default: ``True``. If ``False``, then the related table won't be
-		automatically created; instead you must manually create it (e.g.,
-		with explicit SQLObject classes for the joins). New in 0.7.1.
+    default: ``True``. If ``False``, then the related table won't be
+    automatically created; instead you must manually create it (e.g.,
+    with explicit SQLObject classes for the joins). New in 0.7.1.
 
 .. note::
-   Let's suppose you have SQLObject-inherited classes Alpha and Beta, 
-   and an AlphasAndBetas used for the many-to-many relationship. 
+   Let's suppose you have SQLObject-inherited classes Alpha and Beta,
+   and an AlphasAndBetas used for the many-to-many relationship.
    AlphasAndBetas contains the alphaIndex Foreign Key column referring
    to Alpha, and the betaIndex FK column referring to Beta.
    if you want a 'betas' RelatedJoin in Alpha, you should add it to
    Alpha passing 'Beta' (class name!) as the first parameter, then
-   passing 'alpha_index_id' as joinColumn, 'beta_index_id' as 
+   passing 'alpha_index_id' as joinColumn, 'beta_index_id' as
    otherColumn, and 'alphas_and_betas' as intermediateTable.
-   
+
 __ `Many-to-Many Relationships`_
 
 An example schema that requires the use of `joinColumn`, `otherColumn`,