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.
william0275 a écrit :
> It really doesn't sound like a strange behviour to me. The Zend_Db_Table_Row
> 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 ?
>>
>>
>>
>
>
没有评论:
发表评论