Re: [Modeling-users] How the transactions are done in the saveChanges?

[Sebastien B. <sbi...@us...>]

        Hi,

Marco Bizzarri wrote:
[...]
> Sebastien Bigaret wrote:
> |>Also, I've noticed that the ec.fetch() is a transaction which 
> |>terminates with an abort. Is this correct?
> |
> |
> | This is intentional, anyhow ;)  Such a transaction should be
> | terminated, and I cannot see any reason why it should be COMMITed, 
> | hence it is ABORTed! But if you think differently, please let us 
> | know!
> 
> One of the basic reason for this is in the debugging/maintenance of 
> the system.
> 
> When you need to look for the DB log, it is useful to spot the 
> problems by mean of ABORTed transactions. If the aborted transactions 
> are the standard, this can be a problem.

Understood, this seems reasonable. I think this could be controlled by
an option / env. variable / whatever

> |>2) how are the db transaction executed/completed inside a Zope 
> |>transaction? In a non-zope application, I can see each fetch() 
> |>produces a transaction, as well as the ec.saveChanges(). Is this 
> |>true also in Zope applications?
> |
> | Yes it is.  The zope support basically consists in providing a
> | default EditingContext per session, possibly also connecting this 
> | EC's saveChanges() to the transaction machinery (i.e. to 
> | request/response loop).  That's all, and everything else will be 
> | handled in your ZProducts' code, just the same way you would make it 
> | in pure python.
> |
> | 	Hope this helps
> 
> Yes and no... I would prefer to be able to tell ModelingFramework when 
> it should start/stop a transaction on the db... howevr, thanks of the 
> answer...

Could you be a little more explicit on your use-case(s)?
I'm curious here, and I'd like to better understand what your needs are
/ could be in terms of finer control on transactions.

-- Sébastien.