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 Sat, 13 Mar 2004 17:00:44 GMT
hi armin, peter,

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 ?

jakob

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

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