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 

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 

For attribute auto-retrieve we don't need three (five) states. In this 
case the old true/false differentiation is sufficient.


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?


> 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

View raw message