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: auto-XXX setting (PART II)
Date Fri, 19 Mar 2004 20:43:41 GMT
hi armin,

do we really want to keep LINK for 1:n and m:n relationships, regardless of the 
problems with referential integrity ?

jakob

Armin Waibel wrote:

> Hi Jakob,
> 
> you describe exactly what I mean.
> 
> Jakob Braeuchi wrote:
> 
>> let me summarize the behaviour for auto-update: none, link, object as 
>> i currently understand it:
>>
>> ------------
>> 1:1 relation
>> ------------
>>
>> - auto-update NONE
>> Referenced object was not insert/update on store of main object. 
>> Referenced object was not modified. User have to assign FK in main 
>> object by hand (calling a PB service method to assign FK).
>>
>> - auto-update LINK
>> Referenced object is NOT inserted/updated. Automatic assignment of FK 
>> in main object.
>> This may violate referential integrity !!
> 
> 
> I think this is current behaviour of OJB for auto-update=false.
> We need this for backward compatibility.
> 
>>
>> - auto-update OBJECT
>> Referenced object insert/update too on store of main object. Automatic 
>> assignment of FK in main object.
>>
> 
> yep! That's same behaviour like auto-update true
> 
>>
>> ------------
>> 1:n relation
>> ------------
>>
>> - auto-update NONE
>> Only the main object will be insert/update, references will ignored. 
>> User has to take care of referenced objects and have to assign FK by 
>> hand (using a PB service method to assign FK)
>>
>> - auto-update LINK
>> On insert/update of the main object all n references will be handled 
>> too. OJB does an automatic FK assignment on all references and what 
>> happends then ???
>> Does this really make sense, because updated references will not be 
>> stored !
>>
> 
> Again I think this is current behaviour of OJB for auto-update=false.
> We need this for backward compatibility.
> 
>> - auto-update OBJECT
>> On insert/update of the main object all n references will be handled 
>> too. OJB does an automatic FK assignment on all references and do 
>> insert/update references too. The FK fields will be set (again) on 
>> each store of the main object.
>>
>> ------------
>> m:n relation
>> ------------
>>
>> - auto-update NONE
>> Insert/update the main object only. User has to insert the references 
>> and populate the indirection table by hand (using a service method to 
>> write the indirection table entries)
>>
>> - auto-update LINK
>> Popuplate the indirection table, but do not insert references.
>> This may violate referential integrity !!
>>
> 
> current behaviour of OJB for auto-update false
> 
>> - auto-update OBJECT
>> Insert/update main object, insert/update all references, write 
>> indirection table entries.
>>
>> i'm not convinced that auto-update: LINK is really useful. but may be 
>> i do not understand it yet.
>>
> 
> The "link" property do we need
> - for backward compatibility
> - as convenience feature (user don't need to call the "link-methods" to 
> assign the FK)
> - allow maximal flexibility in handling of references
> 
> The gain of the three new properties (none, link, object) is the 'none' 
> property - allows update of the main object without touching the 
> references.
> 
> Really useful is 'link' for 1:1 when the reference object already exists 
> or for m:n references to link existing objects.
> 
> regards,
> Armin
> 
> 
>> jakob
>>
>>> Hi Peter,
>>>
>>> Peter Wieland wrote:
>>>
>>> ...
>>>
>>>> I see your point. Effectively, it is not always reasonable to 
>>>> autoupdate
>>>> references (fill the indirection table) especially with
>>>> auto-retrieve="false". In fact, auto-retrieve="false" disables 
>>>> automatic
>>>> handling of references when loading objects. So it seems quite 
>>>> normal that
>>>> enableing automatic handling of references when saving these objects 
>>>> leads
>>>> to unexpected behaviour.
>>>>
>>>> But I think that there are many other scenarios where auto-linking 
>>>> objects,
>>>> i.e. auto-updating references, makes much sense. E.g. when
>>>> auto-retrieve="true" and consequently n-side objects are already 
>>>> loaded when
>>>> storing the object.
>>>>
>>>
>>> agree a transparent auto-link feature will be useful.
>>>
>>> ...
>>>
>>>>
>>>> Sounds interesting to me. How about introducing an additional attribute
>>>> auto-link or auto-connect in the collection-descriptor. At this 
>>>> point, I
>>>> think this would be a very simple step. With 
>>>> auto-link/connect="true", OJB
>>>> would automatically connect/link the collection elements to the parent
>>>> object, i.e. call the corresponding broker.connect or broker.link 
>>>> methods.
>>>> With auto-link/connect="false", the behaviour would be the one 
>>>> defined by
>>>> Armin in his proposal.
>>>>
>>>> This way, I think, users would be flexible to avoid materializing 
>>>> objects as
>>>> in the Actor/Movie scenario and at the same time, they could 
>>>> configure OJB
>>>> to handle all connecting/linking stuff transparently where it seems
>>>> indicated.
>>>>
>>>> Additionally, we would have clear separation between auto-updating
>>>> references and auto-updating referenced objects.
>>>>
>>>> One point to think about is in what way auto-update and 
>>>> auto-link/connect
>>>> would depend on each other. I think auto-update="true" implies
>>>> auto-link/connect="true". We could therefore use one single attribute
>>>> auto-update with values NONE, LINKS, OBJECTS.
>>>
>>>
>>>
>>>
>>> Differ between auto-xxx references and referenced objects is really 
>>> smart. I don't like the idea of introducing another attribute 
>>> auto-link, but I like the expansion of the auto-xxx states.
>>>
>>> Allow all auto-xxx attributes to be in state NONE, LINK, OBJECT and 
>>> to be backward compatible FALSE, TRUE too (both states will be 
>>> declared deprecated).
>>>
>>> Means we allow five states for each auto-xxx attribute.
>>>
>>> FALSE is same as LINK, TRUE is same as OBJECT (we should have a 
>>> closely look in current implementation if the correlation 
>>> false-->link and true-->object does match for all types (?retrieve?, 
>>> update, delete) of references).
>>>
>>> For attribute auto-retrieve we don't need three (five) states. In 
>>> this case the old true/false differentiation is sufficient.
>>>
>>> conclusion:
>>>
>>> auto-retrieve: true, false
>>> auto-update: none, link, object, (true), (false)
>>> auto-delete: none, link, object, (true), (false)
>>>
>>> plus new methods for "object linking by hand"
>>>
>>> Or do we really need an additional attribute?
>>>
>>> regards,
>>> Armin
>>>
>>>> This way we would prevent the
>>>> repository from having inconsistent attributes auto-update="true" and
>>>> auto-link/connect="false", but this would oblige users to change 
>>>> current
>>>> repositories. With two distinct attributes and a sensible default 
>>>> value for
>>>> the new auto-link/connect attribute, the old repositories would be
>>>> compatible to the new dtd. We could simply ignore the auto-link/connect
>>>> setting when auto-update="true".
>>>>
>>>> What do you say?
>>>>
>>>> Peter
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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