From: Edmund L. <el...@in...> - 2001-12-26 05:28:23
|
I'm wondering how MiddleKit users are dealing with the issue of transactions. As far as I can tell, the notion of commits and rollbacks are not fully implemented in ObjectStore.py--methods like revertChanges(self) raise NotImplemented errors). Why I ask is because I'm used to the traditional RDBMS notions of transactions (and ACIDity) and not at all used to using an object-relational layer. I think that there might be situations where one wants to commit several objects to persistant storage atomically, but without support for transactions in MiddleKit (or MySQL for that matter), how does everybody cope? Do you really drop down to unwinding your .saveChanges() method calls by hand (i.e., with code)? Isn't this a bit icky? ...Edmund. |
From: Chuck E. <Chu...@ya...> - 2001-12-27 06:06:40
|
On Tuesday 25 December 2001 09:30 pm, Edmund Lian wrote: > I'm wondering how MiddleKit users are dealing with the issue of > transactions. As far as I can tell, the notion of commits and > rollbacks are not fully implemented in ObjectStore.py--methods like > revertChanges(self) raise NotImplemented errors). > > Why I ask is because I'm used to the traditional RDBMS notions of > transactions (and ACIDity) and not at all used to using an > object-relational layer. I think that there might be situations where > one wants to commit several objects to persistant storage atomically, > but without support for transactions in MiddleKit (or MySQL for that > matter), how does everybody cope? Do you really drop down to > unwinding your .saveChanges() method calls by hand (i.e., with code)? > Isn't this a bit icky? > > ...Edmund. MiddleKit (MK) doesn't have transaction support. In my applications, this has not been critical since [a] we've never experienced a failure and [b] our data is valuable, but not necessarily "mission critical" (like a customer checking account balance). Nevertheless MK _should_ support transactions, but this feature implementation is not scheduled any time soon (unless you want to contract me for it). Interestingly, I've heard (but not confirmed) that the Python Programming Patterns book builds an OO multithreaded transaction module/tool/whatever. That could be useful input. Also, there will be some kind of meeting or BOF about ORM, transactions, etc. involving both MiddleKit and ZODB folks at Python 10. In the present, your choices are to live without this or build it. If you choose the latter, I would be happy to answer your questions and have discussions about it. I designed and wrote most of MK, and Geoff T did some major work as well (delete, bugfixes, etc.). BTW Your question was not dumb. :-) -Chuck |
From: Stefan K. <st...@ev...> - 2001-12-28 20:03:15
|
On Wed, 26 Dec 2001 00:30:40 -0500, Edmund Lian wrote: >I'm wondering how MiddleKit users are dealing with the issue of >transactions. As far as I can tell, the notion of commits and >rollbacks are >not fully implemented in ObjectStore.py--methods like >revertChanges(self) >raise NotImplemented errors). > >Why I ask is because I'm used to the traditional RDBMS notions= of >transactions (and ACIDity) and not at all used to using an >object-relational layer. I think that there might be situations >where one >wants to commit several objects to persistant storage= atomically, but >without support for transactions in MiddleKit (or MySQL for= that >matter), >how does everybody cope? Do you really drop down to unwinding= your >..saveChanges() method calls by hand (i.e., with code)? Isn't= this a >bit >icky? Tip: If you want to have very simple MK/MySQL support of= transactions you can do like this (at least it works for me :-). 1) Subclass MySQLObjectStore and override saveChanges: class MyMySQLObjectStore(MySQLObjectStore): def saveChanges(self): self.executeSQL('BEGIN') try: MySQLObjectStore.saveChanges(self) except Exception, e: self.executeSQL('ROLLBACK') raise e else: self.executeSQL('COMMIT') 2) Make sure that your MySQL server supports transactions, i.e= install InnoDB. You don't need 4.0 to do this, a recent 3.23 is OK. The prebuilt= Windows binaries already have InnoDB installed but on Linux you may have= to install it separately. Read more about this on http://www.mysql.com/. 3) Edit GeneratedSQL/Create.sql and add TYPE=3DInnoDB after every= create table: create table MyClass ( myClassId int not null primary key= auto_increment, ) TYPE=3DInnoDB; The last step must be repeated every time you generate your SQL= files from the object model :-( But if we ask Chuck kindly he might fix this in the MK generate= stuff :-). It would be perfect if one could set an option in= Settings.config, like 'MySQLTableType':'InnoDB'. /Stefan |
From: Chuck E. <Chu...@ya...> - 2001-12-31 04:14:34
|
On Friday 28 December 2001 12:03 pm, Stefan Karlsson wrote: > Tip: If you want to have very simple MK/MySQL support of transactions > you can do like this (at least it works for me :-). > > 1) Subclass MySQLObjectStore and override saveChanges: > > class MyMySQLObjectStore(MySQLObjectStore): > def saveChanges(self): > self.executeSQL('BEGIN') > try: > MySQLObjectStore.saveChanges(self) > except Exception, e: > self.executeSQL('ROLLBACK') > raise e > else: > self.executeSQL('COMMIT') Should this also be a setting? 'SQLSaveChanges': ['BEGIN', 'ROLLBACK', 'COMMIT'], Or are these always the same? So then: 'SQLCommitOrRollBack': 1, (Most of my experience is with MySQL so I'm less familar with other db's.) > 3) Edit GeneratedSQL/Create.sql and add TYPE=InnoDB after every > create table: > > create table MyClass ( > myClassId int not null primary key > auto_increment, ) TYPE=InnoDB; > > > The last step must be repeated every time you generate your SQL files > from the object model :-( > But if we ask Chuck kindly he might fix this in the MK generate stuff > :-). It would be perfect if one could set an option in > Settings.config, like 'MySQLTableType':'InnoDB'. I agree that a setting is the way to go. Is there a notion of "table type" in any other flavor of SQL? Perhaps the setting should just be "SQLTableType". -Chuck |
From: Stefan K. <st...@ev...> - 2002-01-04 08:49:49
|
On Sun, 30 Dec 2001 20:14:33 -0800, Chuck Esterbrook wrote: >On Friday 28 December 2001 12:03 pm, Stefan Karlsson wrote: >>=A0Tip: If you want to have very simple MK/MySQL support of >>transactions >>=A0you can do like this (at least it works for me :-). >> >>=A01) Subclass MySQLObjectStore and override saveChanges: >> >>=A0class MyMySQLObjectStore(MySQLObjectStore): >>=A0=A0=A0def saveChanges(self): >>=A0=A0=A0=A0=A0self.executeSQL('BEGIN') >>=A0=A0=A0=A0=A0try: >>=A0=A0=A0=A0=A0=A0=A0MySQLObjectStore.saveChanges(self) >>=A0=A0=A0=A0=A0except Exception, e: >>=A0=A0=A0=A0=A0=A0=A0self.executeSQL('ROLLBACK') >>=A0=A0=A0=A0=A0=A0=A0raise e >>=A0=A0=A0=A0=A0else: >>=A0=A0=A0=A0=A0=A0=A0self.executeSQL('COMMIT') > >Should this also be a setting? Maybe a good idea > >=A0=A0=A0=A0'SQLSaveChanges': ['BEGIN', 'ROLLBACK', 'COMMIT'], > >Or are these always the same? So then: > >=A0=A0=A0=A0'SQLCommitOrRollBack': 1, > >(Most of my experience is with MySQL so I'm less familar with= other >db's.) BEGIN, ROLLBACK and COMMIT also work in Postgres, don't know= about other db's. > > >>=A03) Edit GeneratedSQL/Create.sql and add TYPE=3DInnoDB after= every >>=A0create table: >> >>=A0create table MyClass ( >>=A0=A0=A0myClassId =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int not null primary key >>=A0auto_increment, ) TYPE=3DInnoDB; >> >> >>=A0The last step must be repeated every time you generate your= SQL >>files >>=A0from the object model :-( >>=A0But if we ask Chuck kindly he might fix this in the MK= generate >>stuff >>=A0:-). It would be perfect if one could set an option in >>=A0Settings.config, like 'MySQLTableType':'InnoDB'. > > >I agree that a setting is the way to go. Is there a notion of= "table >type" in any other flavor of SQL? Perhaps the setting should= just be >"SQLTableType". I think this is not standard. I only know MySQL having table= types. /Stefan |
From: Geoffrey T. <gta...@me...> - 2002-01-04 13:39:02
|
On Friday January 04, 2002 03:50 am, Stefan Karlsson wrote: > On Sun, 30 Dec 2001 20:14:33 -0800, Chuck Esterbrook wrote: > >On Friday 28 December 2001 12:03 pm, Stefan Karlsson wrote: > >>=A0Tip: If you want to have very simple MK/MySQL support of > >>transactions > >>=A0you can do like this (at least it works for me :-). > >> > >>=A01) Subclass MySQLObjectStore and override saveChanges: > >> > >>=A0class MyMySQLObjectStore(MySQLObjectStore): > >>=A0=A0=A0def saveChanges(self): > >>=A0=A0=A0=A0=A0self.executeSQL('BEGIN') > >>=A0=A0=A0=A0=A0try: > >>=A0=A0=A0=A0=A0=A0=A0MySQLObjectStore.saveChanges(self) > >>=A0=A0=A0=A0=A0except Exception, e: > >>=A0=A0=A0=A0=A0=A0=A0self.executeSQL('ROLLBACK') > >>=A0=A0=A0=A0=A0=A0=A0raise e > >>=A0=A0=A0=A0=A0else: > >>=A0=A0=A0=A0=A0=A0=A0self.executeSQL('COMMIT') > > > >Should this also be a setting? > > Maybe a good idea > > >=A0=A0=A0=A0'SQLSaveChanges': ['BEGIN', 'ROLLBACK', 'COMMIT'], > > > >Or are these always the same? So then: > > > >=A0=A0=A0=A0'SQLCommitOrRollBack': 1, > > > >(Most of my experience is with MySQL so I'm less familar with other > >db's.) > > BEGIN, ROLLBACK and COMMIT also work in Postgres, don't know about othe= r > db's. I'm pretty sure MS SQL Server requires "BEGIN TRAN" or "BEGIN TRANSACTION= ",=20 not just "BEGIN". Same for ROLLBACK and COMMIT. - Geoff |