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 13:29:16 GMT
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


Mime
View raw message