> If you want that level of control, why don't you create an object for
> your indirection table?
Because I like the conceptual idea of non-decomposed relations as implemented in OJB.
I mean, when you have designed your high-level domain objects model, you do not
think about these "relationtable" type of objects that only consist of two "foreign
keys".
Your domain objects when mapped to Java simply have "collections of other objects",
and the model is high-level and simple to draw.
But when the database grows much bigger and I look at the actual database statements,
and the resulting performance implications, I get the feeling that it does not scale
well.
Maybe you are absolutely right, and using an actual object is a better solution.
But then what is the value of the OJB implementation ?
Anyone actually using it for non-trivial size database ?
Thanks for your reply,
Theo
> -----Original Message -----
> From: Gelhar, Wallace J. [mailto:[EMAIL PROTECTED]
> Sent: maandag 10 maart 2003 18:11
> To: OJB Users List
> Subject: RE: A better way to manage m:n relations ?
>
>
> If you want that level of control, why don't you create an object for
> your indirection table?
>
> Wally
>
> -----Original Message-----
> From: Theo Niemeijer [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2003 10:59 AM
> To: OJB Users List
> Subject: A better way to manage m:n relations ?
>
>
>
> Hi all.
>
> Something that still bothers me when using OJB is the way I have to
> manage my non-decomposed m:n relationships.
>
> Because the indirection tabel is not directly accessible as domain
> objects, I have to fill a vector with references to the related objects,
>
> and then do a store on the main object.
>
> OJB will then delete all the n:m relation entries for that object in the
>
> indirection tabel, and then recreate them from the collection.
> (As far as i can see using the P6spy and the sources)
>
> I would think it would be easier and more efficient if there would
> be a method "link" that would insert a relation, and a method "unlink"
> that
> would remove a relationship. Without such methods I will always have
> unneccessary store actions on the main object.
>
> [Note that I am only using the Perstince Broker, not the higher level
> API's]
>
> An alternative would be to use a collection that would implement this
> under its covers, so it would do "link" and "unlink" via its interface
> methods add(Object), addAll(Collection), remove(Object)
> removeAll(Collection).
>
> Is there anyone out there using n:m collections that found a way to
> avoid these redundant stores and deleta activities ?
>
>
> Regards,
> Theo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
