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 Thu, 18 Mar 2004 00:54:25 GMT
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


Mime
View raw message