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: auto-XXX setting (PART II)
Date Mon, 22 Mar 2004 20:14:15 GMT
Hi Jakob,

Jakob Braeuchi wrote:

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

hmm, I see this problem too. But we need this setting for backward
compatibility. We can hide LINK, so that the user can't use this 
setting. But I think if we clearly document the new (and old) settings 
it shouldn't cause problems. What do you prefer?

How should we handle auto-delete (NONE; LINK; OBJECT)??
Here my proposals:

------------
1:1 relation
------------
- auto-delete NONE
only delete the main object

- auto-delete LINK
same as above

- auto-delete OBJECT
delete main object and reference too

------------
1:n relation
------------
- auto-delete NONE
only delete main object, user have to unlink n-side references by hand 
using service methods

- auto-delete LINK
set all FK fields of the references to 'null' and perform an update
on these objects, delete main object

- auto-delete OBJECT
delete all references and the main object


------------
m:n relation
------------
- auto-delete NONE
only delete main object, user have unlink references by hand using 
service methods (removing indirection table entries)

- auto-delete LINK
remove all entries of main object in indirection table and delete main 
object

- auto-delete OBJECT
remove all entries of main object and referenced objects in indirection 
table and remove main object and all referenced objects.

regards,
Armin

> 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
> 
> 
> 






---------------------------------------------------------------------
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