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 Wed, 24 Mar 2004 17:04:11 GMT
hi armin,

Armin Waibel wrote:
> 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?

after some more thinking, i do not like updating the referenced objects ;)

to update all of them we need to load them before, this may be an issue if the 
n-side contains many objects.

jakob

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

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