and Zend_Db_Table classes don't know you're in a transaction, and should
*not* be aware of it, it's not their business. The Zend_Db_Table_Row will
update itself from the database after an insert, and it does it using the
last_insert_id(). It works and it does it's job.
Now, if you have an exception and rollback, your whole Zend_Db_Table_Row
instance becomes invalid. It's your job to know that, and to instantiate a
new one, a valid one. I see it as a programming error, where you're using a
newly created row that isn't even valid.
Lucas Corbeaux wrote:
>
> Hi,
>
> I write (again... ;)) to the list because a little thing happen to me
> this afternoon, wich seems really... Surprising in a first time (even if
> I doubt that can be "fixed") and cause to me some headaches before
> finding the reason.
>
> Imagine such an example:
>
> $users_table->getAdapter()->beginTransaction();
> $user = $users_table->createRow();
> // Things to do...
> try {
> $user->save();
> users_table->getAdapter()->commit();
> }
> catch (Zend_Db_Exception $e) {
> users_table->getAdapter()->rollback();
> }
>
> A call of echo $user->id; will display the temporary id given by the
> save() method, regardless of the current transaction was or not
> comited... It's not really worrying... Except when you keep the $user
> object into session during a long signup procedure... If an exception
> occured and the transaction rollback, object keep the "recorded" state,
> and can't be saved later (exception is thrown in the _refresh method, as
> no "parent row were found").
>
> I just want to know if that fact is well knowned of Zend Framework's
> users, or if I was the only one surprised of that behaviour. Any chance
> that, in future versions, row objects will be aware of the current
> transaction state ?
>
>
--
View this message in context: http://www.nabble.com/Zend_Db_Table_Row%3A%3Asave%28%29-and-transactions...-tp22209849p22210764.html
Sent from the Zend DB mailing list archive at Nabble.com.
没有评论:
发表评论