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

[Marco B. <m.b...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sebastien Bigaret wrote:
|         Hi,
|
| Marco Bizzarri wrote:
[...]
|>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
|

That would be great :)


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

Up to now we have used SQL transactions inside the Zope TM. This means
that, for each request/response, you've just one transaction, which is
either commited or aborted.

The Modeling Framework, on the other hand, would perform several
transactions on RDBMS,

This could be a problem since I could see, inside a transaction,
possibily different values for the same row. Of course I could decide to
manage directly these issues, but I would prefer to have them handled by
the Modeling Framework.

Let's say I've two classes, Customer and Order. The association is one
to many from Customer to Order.

Now let's say I'm retrieve a Customer C, using an ec.fetch(),  which
causes an RDBMS transaction. After this, another thread commits
something, modifying both the Customer and its orders. I then retrieve
the Orders, which is another RDBMS transaction. Data on the order are up
to date, but not on the Customer.

Actually, I would not having to deal with RDBMS transactions at all.
Instead, I would prefer to see a single BEGIN/COMMIT, or BEGIN/ABORT for
each of my Zope Transaction.

| -- Sébastien.

Regards
Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBIz2DXhfyAQQVoaIRAj4FAJ9Lf7OMeTO9GhdfVmGUkzSL5tVbTwCdGuKF
50IZki3s5k7I8Vsf+NjmmqI=
=ZzDr
-----END PGP SIGNATURE-----