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 Sat, 13 Mar 2004 01:08:23 GMT
Hi Peter,

Peter Wieland wrote:

> Hi Armin, Jakob and the others,
> 
> thanks for your mail Armin, The auto-XXX attributes become very clear in
> your proposals.
> 
> But I'm not sure whether this is really what we need. My skepticism is
> espacially related to the auto-update behaviour you propose for m:n
> relations.
> 
> I'm not sure whether it is really a good idea to leave it to the application
> programmer to store indirection table entries. While in some cases using
> auto-update="true" would be an acceptable solution, I don't think that it is
> always the desired behaviour. I think the possibility to just update the
> references, i.e. the entries in the indirection table, would be a good
> thing.

This will be possible too.

Method "assignMtoNIndirectionTable(Object obj, String attributeName)"
will be used to create the entries in the indirection table on insert of 
the main object with auto-update false:

broker.beginTransaction
broker.store(A)
A.setAllB(bList)
// auto-update false we do this by hand
while(bListIterator.hasNext())
{
    broker.store(bListIterator.next())
}
// additional line to populate indirection table
broker....assignMtoNIndirectionTable(A, bListAttribute)
broker.commitTransaction

If you only want update the indirection table do
broker.beginTransaction
bList = A.getAllB();
bList.add(additional B object)
broker....assignMtoNIndirectionTable(A, bListAttribute)
broker.commitTransaction
This will insert a new entry in indirection table for the additional B 
object (if B already exists in DB).

> 
> Another argument supporting this request is that from an application
> programmers point of view, there is no difference in storing the n side of a
> 1:n relation or storing one side of a m:n relation. Hence I think we should
> not require special treatment for m:n relations with auto-update="false".
> 

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.

regards,
Armin

> What do you think?
> 
> 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