db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Possible problem in CollectionProxyDefaultImpl
Date Sat, 03 Jul 2004 18:26:15 GMT
hi armin, bogdan,

i commited some fixes to the trunk to solve this problem.

what about commiting fixes to the branch ? do i have to wait for brian ?

jakob

Jakob Braeuchi wrote:
> hi armin,
> 
> there's a problem in MtoNTest#testDeletionWithClearedList. this testcase 
> clears the list and assumes that the referenced objects are also 
> deleted. but this can be fixed easily.
> 
> jakob
> 
> Armin Waibel wrote:
> 
>> Jakob Braeuchi wrote:
>>
>>> hi armin,
>>>
>>> you're right auto-update="true" is treated as "object".
>>>
>>> i did a check to call ManageableCollection#afterStore only when 
>>> CASCADE_OBJECT is used :
>>>
>>> ...
>>> // if CASCADE_NONE was set, do nothing with referenced objects
>>> if (cod.getCascadingStore() != ObjectReferenceDescriptor.CASCADE_NONE)
>>> {
>>>     Object referencedObjects = cod.getPersistentField().get(obj);
>>>     if (cod.isMtoNRelation())
>>>     {
>>>            storeAndLinkMtoN(false, obj, cod, referencedObjects, insert);
>>>     }
>>>     else
>>>     {
>>>           storeAndLinkOneToMany(false, obj, cod, referencedObjects, 
>>> insert);
>>>     }
>>>
>>>     // BRJ: only when auto-update = object
>>>     if ((cod.getCascadingStore() == 
>>> ObjectReferenceDescriptor.CASCADE_OBJECT)
>>>              && (referencedObjects instanceof ManageableCollection))
>>>     {
>>>         ((ManageableCollection) referencedObjects).afterStore(this);
>>>     }
>>> }
>>>
>>> ...
>>>
>>> actually i'm not sure whether this is always correct. but it prevents 
>>> the n-side objects from being deleted when CASCADE_LINK is used.
>>>
>>
>> hmm, sounds like a good idea! But I'm not sure about side-effects too.
>>
>>
>>
>>> the other solution would be to avoid using RAC for m:n-relationships. 
>>> but then i do not know how CASCADE_OBJECT should work ?
>>>
>>
>> Maybe we need some more tests. Currently all tests pass when non-RAC 
>> collections are used. But I'm not sure if there was a test check 
>> remove of one collection entry and then update the main object. Please 
>> have a look in M2NTest.java.
>>
>> Armin
>>
>>
>>> jakob
>>>
>>>
>>> Armin Waibel wrote:
>>>
>>>> Hi Jakob,
>>>>
>>>> Jakob Braeuchi wrote:
>>>>
>>>>> hi bogdan, armin and all the others
>>>>>
>>>>> the problem here needs further investigations. there seems to be a 
>>>>> mismatch between auto-update and RemovalAwareCollections regarding 
>>>>> m:n relationships.
>>>>>
>>>>
>>>> yes indeed! RemovalAwareCollection should not be used in m:n 
>>>> collections. A notice is in documentation.
>>>> http://db.apache.org/ojb/docu/guides/basic-technique.html#Mapping+m%3An+associations

>>>>
>>>>
>>>> The problem is that RAC is the default collection used in relations.
>>>>
>>>>
>>>>> auto_update has three options : none, link and object.
>>>>> the associated object should only be deleted when the opten is set 
>>>>> to 'object'. if it's 'link' only the intermediary table should be 
>>>>> affected for m:n relationsip 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> yep, without RAC m:n relation should work in that way.
>>>>
>>>>
>>>> (what about 1:n ? link == object ?). afaik the
>>>>
>>>> hmm, I think 'link' can be useful in 1:n when e.g. the main object 
>>>> should be removed, but the n-objects should stay in DB, thus 'link' 
>>>> or in that case 'unlink' only remove the FK entries on n-side 
>>>> objects and then remove the main object.
>>>>
>>>>
>>>>> deprecated option 'true' is treated like 'link'.
>>>>>
>>>>
>>>> Are you sure? I think it's treated like 'object' in 1:n and m:n.
>>>>
>>>>
>>>>> the method storeCollections in PersistenceBrokerImpl only checks 
>>>>> for auto_update <> none and does not distinguish options link and

>>>>> object when calling afterStore !
>>>>>
>>>>
>>>> can describe a little more detailed, don't know what you mean.
>>>> Do you mean sequenceManager.afterStore?
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>
>>>>> jakob
>>>>>
>>>>> Jakob Braeuchi wrote:
>>>>>
>>>>>> hi bogdan, armin,
>>>>>>
>>>>>> actually i see two solutions for this problem:
>>>>>>
>>>>>> 1.) the collection class for an m:n relationship can not be a 
>>>>>> RemovalAwareCollection
>>>>>> 2.) PersistenceBrokerImpl.storeCollections() does no call after 
>>>>>> store for m:n relationship.
>>>>>>
>>>>>> what do you think ?
>>>>>>
>>>>>> jakob
>>>>>>
>>>>>> Jakob Braeuchi wrote:
>>>>>>
>>>>>>> hi bogdan,
>>>>>>>
>>>>>>> this seems to be a problem indeed. by setting the new collection

>>>>>>> in CollectionProxyDefaultImpl.clear() the method afterStore will

>>>>>>> never be able to delete removed elements. imo this is an error.
>>>>>>>
>>>>>>> for m:n-collections actually deleting the removed referenced

>>>>>>> object is a problem because we actually only want to delete the

>>>>>>> reference.
>>>>>>>
>>>>>>> i'll dig a little deeper.
>>>>>>>
>>>>>>> jakob
>>>>>>>
>>>>>>> Bogdan Daniliuc wrote:
>>>>>>>
>>>>>>>>  Hi All,
>>>>>>>>
>>>>>>>>  We are encountering a problem when using proxy with 
>>>>>>>> collections. We are usnig OJB 1.0 with PB API.
>>>>>>>>
>>>>>>>>  Consider the following scenario: there is a class A that
has a 
>>>>>>>> List of elements of type B (one-to-many relationship).
>>>>>>>>
>>>>>>>> The mapping looks like:
>>>>>>>>
>>>>>>>>  <class-descriptor class="test.A" table="A">
>>>>>>>>    <field-descriptor
>>>>>>>>        name="id"
>>>>>>>>        column="ID"
>>>>>>>>        autoincrement="true"
>>>>>>>>        primarykey="true"
>>>>>>>>        jdbc-type="BIGINT"
>>>>>>>>    />
>>>>>>>> ...
>>>>>>>>    <collection-descriptor
>>>>>>>>        name="elements"
>>>>>>>>        element-class-ref="test.B"
>>>>>>>>        proxy="true"
>>>>>>>>        auto-update="true">
>>>>>>>>        <inverse-foreignkey field-ref="objectId"/>
>>>>>>>>    </collection-descriptor>
>>>>>>>>  </class-descriptor>
>>>>>>>>
>>>>>>>>  Now assume that in the database there is an entry for A
that 
>>>>>>>> has several associated B elements. In the code we do the
>>>>>>>>
>>>>>>>> following:
>>>>>>>>    ...
>>>>>>>>       broker = PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>>    A bean = (A)broker.getObjectByQuery(q);
>>>>>>>>
>>>>>>>>    broker.beginTransaction();
>>>>>>>>    List list = bean.getElements();
>>>>>>>>    list.clear();
>>>>>>>>    broker.store(bean);
>>>>>>>>    broker.commitTransaction();     ...
>>>>>>>>
>>>>>>>>   With proxy="true" in the above descriptor, nothing happends

>>>>>>>> when the above code is executed. If we set
>>>>>>>>
>>>>>>>> proxy="false", all elements are deleted. The same thing (elemets

>>>>>>>> are deleted) happends with proxy="true" and if we use
>>>>>>>>
>>>>>>>> remove() on each element of the list instead of clear().
   We 
>>>>>>>> tracked the problem in CollectionProxyDefaultImpl.clear().
More 
>>>>>>>> specifically, after the collection is cleared, a new collection

>>>>>>>> is created and replaces tha original one. If we comment the
code 
>>>>>>>> that replaces the collection, the behaviour is the same with

>>>>>>>> proxy="true" and with proxy="false". However, in this case,
the 
>>>>>>>> junit test testDeleteUnidirectional fails with foreign key

>>>>>>>> violation exception.
>>>>>>>>   Is this a known problem?
>>>>>>>>
>>>>>>>>   Regards,
>>>>>>>>
>>>>>>>>   Bogdan Daniliuc
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------

>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message