100% right point, Pavel

On Monday, June 30, 2014 8:30:11 PM UTC+5, Pavel Horal wrote:
>
> Disclamer - I am experienced Hibernate user and a bit fresh Doctrine user 
> (however with two projects based on it already).
>
> I have stumbled upon this issue and it made me quite upset. The comment 
> explains the behavior, however that behavior is absolutely unacceptable 
> from both user and framework design point of view. 
>
>
>    - In my opinion postRemove event loses 90% of its usefulness. Not 
>    knowing OID of the deleted entity is a fatal flaw.
>    - Advising workaround with some artificial field (
>    http://www.doctrine-project.org/jira/browse/DDC-1680) is unacceptable.
>    - What I see as a more severe logical design flaw: 
>    - How can Doctrine justify gratuitous entity modification? I am 
>       deleting the entity, not asking Doctrine to alter its fields. 
>       - Either Doctrine needs to store / recognize entity state 
>       differently or it would even make much more sense to fail on SQL UPDATE 
>       when someone calls MERGE than to actually clear the identifier.
>    
> So in my opinion there are two things to do:
>
>    - Create BUG for this behavior as there is NO VALID reasoning you can 
>    provide to justify those few lines of code.
>    - If you refuse to see this as a BUG a FEATURE REQUEST should be 
>    created to add OID of the deleted entity to the EVENT object so that 
>    postRemove handler can be used properly.
>
> Regards,
> Pavel Horal
> Dne úterý, 6. března 2012 5:24:03 UTC+1 Marco Pivetta napsal(a):
>>
>> Check comments around
>>
>> https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L1008
>>
>>             // Entity with this $oid after deletion treated as NEW, even if 
>> the $oid
>>             // is obtained by a new entity because the old one went out of 
>> scope.
>>             //$this->entityStates[$oid] = self::STATE_NEW;
>>             if ( ! $class->isIdentifierNatural()) {
>>                 $class->reflFields[$class->identifier[0]]->setValue($entity, 
>> null);
>>             }
>>
>>
>> They actually make sense ;)
>> Marco Pivetta 
>> http://twitter.com/Ocramius      
>> http://marco-pivetta.com     
>>
>> On 3 March 2012 01:53, red9 <[email protected]> wrote:
>>
>>> It seems that in the postRemove lifecycle event the primary key is 
>>> already null. the rest of the object is intact (eg all other fields).  Is 
>>> this a bug or by design?  It seems odd that everything is available in the 
>>> postRemove event except for the primary key.
>>>
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to