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 21:26:51 GMT
Hi again,

Jakob Braeuchi wrote:
>>> 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?
> 
> 
> the LINK-type will be the default, although i do not like it :(
> 

yes, default type is 'false' (in repository.dtd) and this is equals with 
'link'. I think we can't change the false--->link mapping in 1.0.x, 
because it will change behaviour of OJB. We should define NONE in 
repository.dtd as default value in later OJB versions.

...
 >> ------------
 >> 1:n relation
 >> ------------
 >> - auto-delete NONE
 >> only delete main object, user have to unlink n-side references by hand
 >> using service methods
 >>
 >
 > ok, with warning about potential referential integrity problems
 >
 >> - auto-delete LINK
 >> set all FK fields of the references to 'null' and perform an update
 >> on these objects, delete main object
 >>
 >
 > ok, with warning about potential referential integrity problems

Only to make sure that you read carefully ;-) you agree to update all 
references with nullified FK fields?

I locally started modifying PBImpl, ObjectReferenceDescriptor,.... and 
it seems to work for auto-update (I will try auto-delete tomorrow). All 
tests pass without any changes.

Now the question is should we check in the new full backward compatible 
auto-xxx stuff before 1.0 (with updated documentation) or wait until 1.1?
I would prefer to check in this stuff, because it allows users to use 
the new auto-xxx NONE type for references.

regards,
Armin


>>
>> 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
>>
> 
> ok
> 
>> ------------
>> 1:n relation
>> ------------
>> - auto-delete NONE
>> only delete main object, user have to unlink n-side references by hand 
>> using service methods
>>
> 
> ok, with warning about potential referential integrity problems
> 
>> - auto-delete LINK
>> set all FK fields of the references to 'null' and perform an update
>> on these objects, delete main object
>>
> 
> ok, with warning about potential referential integrity problems
> 
>> - 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)
>>
> 
> the problem here is that the indirection table normally needs the 
> referenced rows to be present. so the users has to remove indirection 
> entries first !
> 
>> - auto-delete LINK
>> remove all entries of main object in indirection table and delete main 
>> object
> 
> 
> LINK is useful here !
> 
>>
>> - auto-delete OBJECT
>> remove all entries of main object and referenced objects in 
>> indirection table and remove main object and all referenced objects.
>>
> 
> ok
> 
> 
> this auto-XXX discussion shows a very interesting problem. many users 
> think that an o/r-mapper like ojb could hide all rdbms specific issues. 
> but that's not true. the auto-XXX settings can only be uses reasonably 
> if you know about referential-integrity.
> 
> jakob
> 
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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