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.
>
没有评论:
发表评论