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 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.
UseExplicitTransaction to switch off the mimic in Dabo.
I think this would allow to support all 4 cases.

> 
>>>> 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.

Uwe


_______________________________________________
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]

Reply via email to