Thread: [SQLObject] More transaction troubles
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Randall R. <ra...@ra...> - 2003-09-06 08:59:05
|
Okay, so I got the current CVS, but transactions still seem to not work. :) >>> r = Person.new(firstName='my', lastName='lastname', connection=trans) >>> r.firstName = 'Bob' >>> trans.commit() >>> r.firstName = 'Billy' >>> trans.rollback() >>> print r.firstName Billy I thought that perhaps I needed to pull an object from the db in order to use transactions with it, so >>> del r >>> q = Person(1, trans) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 407, in __new__ val._init(id, connection, selectResults) File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 665, in _init selectResults = (connection or self._connection)._SO_selectOne(self, dbNames) AttributeError: 'Transaction' object has no attribute '_SO_selectOne' Thoughts? :) -- Randall Randall <ra...@ra...> "You assist an evil system most effectively by obeying its orders and decrees." -- Mahatma Gandhi "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Sidnei da S. <si...@pl...> - 2003-09-06 12:41:14
|
On Sat, Sep 06, 2003 at 04:58:49AM -0400, Randall Randall wrote: | Okay, so I got the current CVS, but transactions | still seem to not work. :) |=20 | >>> r =3D Person.new(firstName=3D'my', lastName=3D'lastname',=20 | connection=3Dtrans) | >>> r.firstName =3D 'Bob' | >>> trans.commit() | >>> r.firstName =3D 'Billy' | >>> trans.rollback() | >>> print r.firstName | Billy A wild guess: rollback() isn't clearing the cache. It is also possible that you *think* you are using transactions, but in fact its not enabled on your database. Those are just guesses though, i havent actually looked at the code. []'s --=20 Sidnei da Silva <si...@pl...> dreamcatching :: making your dreams come true http://dreamcatcher.homeunix.org I *____=08=08=08=08knew* I had some reason for not logging you off... If I = could just remember what it was. |
From: Randall R. <ra...@ra...> - 2003-09-06 14:35:11
|
On Saturday, September 6, 2003, at 08:37 AM, Sidnei da Silva wrote: > On Sat, Sep 06, 2003 at 04:58:49AM -0400, Randall Randall wrote: > | >>> r.firstName = 'Billy' > | >>> trans.rollback() > | >>> print r.firstName > | Billy > > A wild guess: rollback() isn't clearing the cache. Just to clarify, I did have _cacheValue = False set in the Person class, which the 0.4 docs say is supposed to be set when planning to use transactions. I'm not sure if that's what you were talking about. > It is also possible > that you *think* you are using transactions, but in fact its not > enabled on your database. I wasn't sure if creating an object could use the Transaction object instead of the connection object, but that's why I tried to re-get it from the database, and got AttributeError: 'Transaction' object has no attribute '_SO_selectOne' which seems like a separate problem in and of itself. > Those are just guesses though, i havent > actually looked at the code. Thanks for the help, though! SQLObject seems very cool; now, if I can only figure out how to use it properly... :) -- Randall Randall <ra...@ra...> "You assist an evil system most effectively by obeying its orders and decrees." -- Mahatma Gandhi "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Ian B. <ia...@co...> - 2003-09-06 18:07:42
|
On Saturday, September 6, 2003, at 03:58 AM, Randall Randall wrote: > Okay, so I got the current CVS, but transactions > still seem to not work. :) > > >>> r = Person.new(firstName='my', lastName='lastname', > connection=trans) > >>> r.firstName = 'Bob' > >>> trans.commit() > >>> r.firstName = 'Billy' > >>> trans.rollback() > >>> print r.firstName > Billy Hmmm... that's odd. Maybe you should give debug=1 to your original connection and see what SQL is being sent. > I thought that perhaps I needed to pull an object from > the db in order to use transactions with it, so > > >>> del r > >>> q = Person(1, trans) > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line > 407, in __new__ > val._init(id, connection, selectResults) > File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line > 665, in _init > selectResults = (connection or > self._connection)._SO_selectOne(self, dbNames) > AttributeError: 'Transaction' object has no attribute '_SO_selectOne' Well, that's just a bug. I'll look into it, I think I have a fix. Of course it will go into CVS and you won't be able to check it for a day. Which brings up the problem of anonymous CVS access on SF. I'll have to write a script to make HEAD available in a more timely manner. Ian |
From: Randall R. <ra...@ra...> - 2003-09-07 10:00:06
|
On Saturday, September 6, 2003, at 02:07 PM, Ian Bicking wrote: > On Saturday, September 6, 2003, at 03:58 AM, Randall Randall wrote: >> Okay, so I got the current CVS, but transactions >> still seem to not work. :) >> >> >>> r = Person.new(firstName='my', lastName='lastname', >> connection=trans) >> >>> r.firstName = 'Bob' >> >>> trans.commit() >> >>> r.firstName = 'Billy' >> >>> trans.rollback() >> >>> print r.firstName >> Billy > > Hmmm... that's odd. Maybe you should give debug=1 to your original > connection and see what SQL is being sent. Okay I did that, and all the SQL looks sane. It appears (from reading source) that Transaction() just passes through any commit() or rollback() it gets to psycopg (in this case), so there isn't any SQL generated from a rollback(). I noticed that there's an "autoCommit" keyword for PostgresConnection(), and the comments imply that it should be turned on for transactions to work, but using it send a "pool" keyword to DBAPI.__init__(), and thence to DBConnection.__init__(), which doesn't expect it. Using the query method of Transaction(), I can see that commit() and rollback() are working okay; I think the reason that transactions didn't appear to work, above, is that SQLObject.new() just ignores the 'connection' keyword (and perhaps that's what it's supposed to do?). Setting _connection to the transaction in the class definition does seem to work, with the exception that a lot of stuff isn't defined for Transaction() that is supposed to be there for a _connection, like '_SO_selectOne', 'queryInsertID', etc. >> AttributeError: 'Transaction' object has no attribute '_SO_selectOne' > > Well, that's just a bug. I'll look into it, I think I have a fix. > Of course it will go into CVS and you won't be able to check it for a > day. Okay. -- Randall Randall <ra...@ra...> "You assist an evil system most effectively by obeying its orders and decrees." -- Mahatma Gandhi "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Ian B. <ia...@co...> - 2003-09-07 18:32:46
|
On Sunday, September 7, 2003, at 05:00 AM, Randall Randall wrote: > Okay I did that, and all the SQL looks sane. It appears (from > reading source) that Transaction() just passes through any > commit() or rollback() it gets to psycopg (in this case), so > there isn't any SQL generated from a rollback(). > > I noticed that there's an "autoCommit" keyword for > PostgresConnection(), and the comments imply that it should > be turned on for transactions to work, but using it send > a "pool" keyword to DBAPI.__init__(), and thence to > DBConnection.__init__(), which doesn't expect it. > > Using the query method of Transaction(), I can see that > commit() and rollback() are working okay; I think the > reason that transactions didn't appear to work, above, > is that SQLObject.new() just ignores the 'connection' > keyword (and perhaps that's what it's supposed to do?). > > Setting _connection to the transaction in the class > definition does seem to work, with the exception that > a lot of stuff isn't defined for Transaction() that > is supposed to be there for a _connection, like > '_SO_selectOne', 'queryInsertID', etc. > Try CVS, I fixed a bunch of these yesterday. Or http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2 Ian |
From: Randall R. <ra...@ra...> - 2003-09-08 23:36:54
|
On Sunday, September 7, 2003, at 02:32 PM, Ian Bicking wrote: >> > Try CVS, I fixed a bunch of these yesterday. Or > http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2 CVS doesn't seem to have changed yet, so I downloaded from colorstudy. In order to get it to install, I had to comment out this line in Col.py: #from include import Validator and change the setup.py packages line to packages=["SQLObject"], # , "SQLObject.include"], because there was no "include" module in the source, and nothing else in SQLObject appears to use Validator. Anyway, I haven't got the chance to fairly test whether transactions are working yet, because I'm using Python 2.2, and this SQLObject doesn't work with it. I'll install 2.3 today and retest. Thanks! -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Ian B. <ia...@co...> - 2003-09-09 01:19:21
|
On Monday, September 8, 2003, at 07:03 AM, Randall Randall wrote: > > On Sunday, September 7, 2003, at 02:32 PM, Ian Bicking wrote: >>> >> Try CVS, I fixed a bunch of these yesterday. Or >> http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2 > > CVS doesn't seem to have changed yet, so I downloaded from colorstudy. > > In order to get it to install, I had to comment out this > line in Col.py: > #from include import Validator Ah, I forgot the -d in cvs up -d for the script that makes that tarball. > and change the setup.py packages line to > packages=["SQLObject"], # , "SQLObject.include"], > because there was no "include" module in the source, > and nothing else in SQLObject appears to use Validator. > > Anyway, I haven't got the chance to fairly test whether > transactions are working yet, because I'm using Python > 2.2, and this SQLObject doesn't work with it. I'll > install 2.3 today and retest. 2.2 should be fine. Are you having a problem with it? Ian |
From: Randall R. <ra...@ra...> - 2003-09-09 09:36:11
|
On Monday, September 8, 2003, at 09:19 PM, Ian Bicking wrote: >> Anyway, I haven't got the chance to fairly test whether >> transactions are working yet, because I'm using Python >> 2.2, and this SQLObject doesn't work with it. I'll >> install 2.3 today and retest. > > 2.2 should be fine. Are you having a problem with it? Yes, but it's a known issue with 2.2, which was fixed sometime later: >>> NTest(1, trans) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 405, in __new__ val._init(id, connection, selectResults) File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 667, in _init selectResults = self._connection._SO_selectOne(self, dbNames) File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line 416, in __getattr__ meth = new.instancemethod(func, self, self.__class__) TypeError: instancemethod() argument 3 must be class, not type Guido mentioned on a mailing list that this was to be fixed in 2.2.1, but since I had no reason to stay with 2.2.x for everything, I just installed 2.3. With Python 2.3, this problem doesn't exist, and everything works swimmingly. Thanks! -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Randall R. <ra...@ra...> - 2003-09-09 06:59:21
|
On Sunday, September 7, 2003, at 02:32 PM, Ian Bicking wrote: > Try CVS, I fixed a bunch of these yesterday. Or > http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2 After installing Python 2.3 and psycopg 1.1.8, transactions seem to work fine. Thanks! -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |