db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Wieland <peter.wiel...@gmx.de>
Subject Re: auto-XXX setting (PART II)
Date Sun, 14 Mar 2004 13:02:48 GMT
Hi Armin, Jakob,

Armin wrote:

> The problem with that behaviour is that you have to load all n-side
> objects before you can update the main object (this current behaviour of
> OJB), if you don't do this, all entries in the indirection table will be
> removed on update of the main object, because OJB could not find n-side
> objects.

> Assume we have classes Movie and Actor (m:n relation). I don't want to
> load all Actors when a Movie object was materialized (e.g. I only want
> to show the top 100 in most cases), so I choose auto-retrieve false in
> collection-descriptor for Movie. In the Actor object I choose
> auto-retrieve true, because if a user choose an Actor I will show all
> movies for this Actor.
> Now I will update an Movie object in DB. Before I can update an Movie
> object I have to load all m:n references for this movie object, because
> the indirection table will be "auto-populated" (that's what you propose
> and OJB currently do) and if no Actors will be found, no entries in the
> indirection table result.
> This is a behaviour I don't expect when doing a simple update of a Movie
> object. Say the movie object to update has 200 Actor references each
> Actor play in 30 movies. Then OJB has to materialize 3000 objects to
> simply update one Movie object. With my proposed behaviour only one
> object will be materialized.

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.

Jakob wrote:

> imo ojb can not properly handle the indirection table when auto-update =
> false. so we have to provide methods to do this manually. but i think
these
> methods should have names that do not smell like rdbms. so any 'fk' stuff
> should be omitted. the main purpose of these methods is connecting (or
> linking) objects to other objects, so we could choose names that reflect
> this behaviour:
>
> broker.connect(objA, objB, relationshipDef)
> or
> broker.link(objA, objB, relationshipDef)
>
> and
>
> broker.connect(objA, collection-of-objB, relationshipDef)
> or
> broker.link(objA, collection-of-objB, relationshipDef)
>
> the behaviour of the method is defined by the relationship-definition. for
> a 1:n
>   relationship the fk pointing from objB to objA is set in objB. in case
of
> m:n the indirection table is populated.
>
> similar methods should be provided to unlink objects.
>
> what do you think about ?

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


Mime
View raw message