inside the try block, this way in the catch block you'll pay a bit
more attention on the objects that need to be discarded. As said
before making the framework to clean your mess would have too many
unwanted consequences, for example if the transaction fails u might
want to take the data from the invalid objects and make something
useful with it, but if the framework would clean your objects, you
would have to start over.
Make sure that you know how your data looks after a catch block in
order to avoid bugs as much as possible (adding $user = null in the
catch block could be an example of knowing what data u must deal with
after the try-catch block)
On Thu, Feb 26, 2009 at 17:14, Lucas Corbeaux <lucas.corbeaux@gmail.com> wrote:
> I know that "linking" a Zend_Db_Adapter and a Zend_Db_Table_Row in this way
> seems a really bad idea, but as I don't consider myself as a Zend Framework
> expert, as I don't work enough with it yet, I'll just ask if some peoples
> other than me was a bit surprised by this behaviour, and if something is
> planned to correct it in the future of if it remains a bad idea.
>
> I'll don't extends my own class for the reasons you said: I'll surely
> encounters huges sides effects that I can't, right now, foresee. As I can't,
> I ask what other people think about it, and if I still believe that in a
> perfect world a transaction rollback would undo some save methods sides
> effects (as generating primary ket), I'm also aware that it could be
> impossible to do this a right and harmless way.
>
> william0275 a écrit :
>>
>> Lucas Corbeaux wrote:
>>
>>>
>>> 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.
>>
>
>
没有评论:
发表评论