Uwe Grauer wrote: > Paul McNett wrote: >> Uwe Grauer wrote: >>> Paul McNett wrote: >>>> Uwe Grauer wrote: >>>>> Paul McNett wrote: >>>> What happens when you set AutoCommit=False for firebird and manage the >>>> commits yourself? >>>> >>> Not possible for firebird. >>> There is no autocommit support in the firebird backend. >>> We would have to mimic this in dabo. >>> See dbCursorMixin.flush() >> I thought you said in your prior message that Dabo mimics Autocommit for >> firebird, so I thought that setting AutoCommit to False might turn off >> that mimicing. >> > > I never got an answer on what AutoCommit should do. > Is it a backend setting or is it a dabo setting? > If i would know that it is a dabo setting, then it is easy to > change dabo to support this. > But then the question is, what to do for explicit transaction handling.
I have my own questions on it as well, as I noted in my first reply this morning. My gut feeling is that we need two properties: 1) Rename AutoCommit to BackendAutoCommit: Is the backend set to commit transactions automatically? This will not be settable for all backends; this will default differently based on the backend. This is a potentially dangerous property, because if you set it in one cursor, it will change all other cursors that use the same connection (because it sets a flag in the db-adapter connection object), so there should be appropriate warnings in the docs. 2) ExplicitTransactions: Default False. Set to True to tell Dabo never to begin, commit, or rollback for this cursor. Put appropriate warnings in the docs that the app dev is responsible for issuing any needed transaction commands. Debatable: setting this to True should/shouldn't set BackendAutoCommit to False. ...but Ed's insight is needed, as he has the full view of the design of the db and biz layers. >>>>> I was willing to do the necessary adjustments for firebird, but couldn't >>>>> get the right answers for my questions. >>>>> See dabo-dev thread "Transaction handling in dabo". >>>> Ok, I began to review that thread, and found as the most recent message >>>> from Ed: >>>> >>>> """ >>>> On Mar 12, 2007, at 10:50 AM, Uwe Grauer wrote: >>>> >>>> > Now i'm asking again: >>>> > How should we make explicit transactions behave like it >>>> > has to be and still have the current behavior to mimic a >>>> > autocommit setting? >>>> >>>> OK, I get it. I will do it myself. When it is posted, please test >>>> and let me know if it works. >>>> """ >>>> >>>> Did nothing come of this? If not, why don't you add a ticket with the >>>> relevant info so we don't forget about it as we go forward. >>>> >>> Nothing was done about this. >>> There is a ticket from about 5 month ago: >>> http://svn.dabodev.com/trac/dabo/ticket/1014 >> Man, that ticket is ugly. We really need to explicitly define the >> problem and format the examples so they aren't a bear to read. >> >> The problem isn't that the different database adapters have implemented >> flush() in different ways, but that transactions are being committed >> automatically when that isn't desired, at least for Firebird. >> >> flush() commits the data, so that is probably working right. However, >> when and where flush() is being called seems to be the problem. >> > > Yes. > We would need: > AutoCommit for the backend if the backend supports it. > AutoCommit mimic in Dabo if the backend doesn't support it. I think that mimic is already there. IOW, if AutoCommit is False, Dabo automatically commits and rolls back when appropriate. Perhaps this is the source of your troubles, now that I think of it. > UseExplicitTransaction to switch off the mimic in Dabo. > I think this would allow to support all 4 cases. I think this sounds good. Again though, I'm going to yield to Ed on this one, because there could well be issues I haven't even thought of. >>>>> I added begin/commit/rollback logging to the DatabaseActivityLog to >>>>> be able to see what dabo is doing for firebird. >>>>> Maybe we should add this for other databases also and write testcases to >>>>> be sure about if it works as it should. >>>> If we could come up with a set of DDL that basically works on all >>>> databases, we could write a test script that turns on the db activity >>>> log, runs the DDL to create the tables, and then does SQL queries using >>>> bizobjs. Then, we could diff the db activity logs to see if all backends >>>> are doing the same things in the same order. >>>> >>> Let's create a test to be able to verify the case. >>> Either we have to precreate a database for this (DDL and DML in one >>> connection is not possible in Firebird) or we have to do DDL and DML in >>> two connections one after another. >> Whatever is needed. Two connections wouldn't be a problem. See my recent >> dabodemo/tutorial/dbEditableGrid.py if you need some boilerplate for how >> to set up Dabo connections in a script. >> > > Ok, let's do it in the next days. I await your script (I understand it'll be for firebird, but hopefully we won't need to modify much to make the same script run the test for sqlite, mysql, etc.) -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
