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:07:03 GMT
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.

the other solution would be to avoid using RAC for m:n-relationships. but then i 
do not know how CASCADE_OBJECT should work ?

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


Mime
View raw message