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 Tue, 16 Mar 2004 01:29:20 GMT
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


Mime
View raw message