nate wrote:
> The way I see it, this is all a part of framework-level support for
> transactions.
Absolutely. It is essential to distinguish between business
transactions (that span multiple connections and can therefore *only*
be handled by the framework) and database transactions (that in
reality, provide a very small contribution to the whole process).
Optimistic locking in cake would certainly get a +1 from me,
The simplest design (conceptually and use-ably (is that a word?), but
probably very interesting to implement) that I can come up with would
be along the lines of:
1. Session->startBusinessTransaction()
2. All Model->save()'s are intercepted and 'parked' in the session with
before/after data
- any subsequent Model->read()'s & find()s are sourced from session
first, if not found then from db
3 Lots of interesting user actions and multiple pages
. . .
4. Session->commitBusinessTransaction()
- Model->read() all models in session
- Compare each freshly read model with session 'before' data
- If *all* models are identical, then Model-save()'s to database
within a database transaction
else rollback and error to user to requery recod(s)
~GreyCells
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Cake PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
