db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Possible problem in CollectionProxyDefaultImpl
Date Sat, 03 Jul 2004 13:26:44 GMT
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


Mime
View raw message