>
> I must admit I don't really agree.
>
> The natural behaviour of a transaction seems to me that all happen
> atomically, and an ORM would, in my sense, be aware of what happened in
> the database layer, whenever it's possible.
> I'm totally aware that a feature like this will broke the object design
> of the Zend_Db module (because that mean store a Zend_Db_Table_Row
> references for "active" rows during a transaction in the Zend_Db_Adapter
> class), but forcing the programmer to be aware of the exact inner
> mechanism of the framework don't seem to me a good thing, even if I
> personnally prefer to look at the source code every time I need.
>
>
But think about it. You instantiate a *new* Zend_Db_Row using
Zend_Db_Table->createRow(), and apply a save() on it. What would you expect
a framework to do when you rollback a transaction? Call some unsave() or
undo() method on your Zend_Db_Table_Row? I think if you rely on the
framework to do your own cleaning, you're going to have other problems than
a simple Zend_Db_Row filled with an invalid primary key... Also, what
happens when you're working on a Zend_Db_Table_Rowset which contains a row
that should disappear after a rollback? You would like the framework to
automatically remove it from the rowset?
Anyhow, it could be an endless debate. You could of course extend your own
class that would do this for you, but I for sure would not want this in the
native framework, it would add too much complexity and potential problems.
--
View this message in context: http://www.nabble.com/Zend_Db_Table_Row%3A%3Asave%28%29-and-transactions...-tp22209849p22223768.html
Sent from the Zend DB mailing list archive at Nabble.com.
没有评论:
发表评论