objectbridge-developers

[OJB-developers] MtoN-followup

[Georg S. <ge...@me...>]

Hi Jacob and Thomas

This is the follow-up to my previous mail talking about the
M:N-Relationship issue:

OK, the basic issue is, that an object should be able to form part of
different collections. The basic example I give is that you could have
an Inventory object which contains a list of Articles, and ShoppingCart
objects which also contain a list of Articles.
I don't think that this is a minor feature, but it is simply the way
objects can be used in Java.

Up to the last release this was possible, but now the entire MtoN-code
has been changed. Now an object A can have a collection of objects B,
but at the same time object B has to have a collection of objects A,
effectively linking A and B tightly together. If you want to have object
A to be part of a collection in an object C, you have to provide a
collection in object B pointing to objects C .....

Object B shouldn't have to know that it is part of a collection in an
M:N scenario.

The only testcase for that MtoN-issue is testMNLoading() in MtoNMapping
which uses the Person-Project relationship, where Person has a
collection of Projects and Project has a collection of Persons.

I have assembled a testcase which should check the form of
MtoN-relationships where the N-Class doesn't have a collection of
M-Objects. Of course it fails right away, but it would be a starting
point to analyze how to fix things.

I have attached the following things:

1.) a method testMultipleMtoNRelations() which should go into the
    MtoNMapping.java file

2.) the files Inventory.java and ShoppingCart.java which go into the same
directory

3.) the mapping for both classes which has to be added to
repository_junit.xml

4.) the create statement for the tables and indirection tables which has
to go into db-setup.sql

Cheers

Georg

[OJB-developers] MtoN-followup

[Jakob B. <jbr...@ho...>]

hi oleg, hi georg,

i reactivated the old QueryByMToNCriteria to solve unidirectional m:n
relationships.
please have a look at it.

jakob

ps: i cannot receive mails for about 5 hours, maybe you've already another
solution

[OJB-developers] MtoN-followup

[Jakob B. <jbr...@fr...>]

hi oleg, hi georg,

i reactivated the old QueryByMToNCriteria to solve unidirectional m:n
relationships.
please have a look at it.

jakob

ps: 
you may already have received this mail.
i cannot receive mails for about 5 hours, maybe you've already another
solution

[OJB-developers] Re: MtoN-followup

[Jakob B. <jbr...@ho...>]

hi georg,

> Up to the last release this was possible, but now the entire MtoN-code
> has been changed. Now an object A can have a collection of objects B,
> but at the same time object B has to have a collection of objects A,
> effectively linking A and B tightly together. If you want to have object
> A to be part of a collection in an object C, you have to provide a
> collection in object B pointing to objects C .....

yes that's true the relationship has to be bidirectional.
i had long discussions with oleg nitz and we both came to this conclusion.
but i see that tight coupling can be a problem.

jakob

----- Original Message -----
From: "Georg Schneider" <ge...@me...>
To: "Mahler Thomas" <tho...@it...>
Cc: <jbr...@ho...>; <obj...@li...>
Sent: Thursday, June 06, 2002 1:50 PM
Subject: MtoN-followup


> Hi Jacob and Thomas
>
> This is the follow-up to my previous mail talking about the
> M:N-Relationship issue:
>
> OK, the basic issue is, that an object should be able to form part of
> different collections. The basic example I give is that you could have
> an Inventory object which contains a list of Articles, and ShoppingCart
> objects which also contain a list of Articles.
> I don't think that this is a minor feature, but it is simply the way
> objects can be used in Java.
>
> Up to the last release this was possible, but now the entire MtoN-code
> has been changed. Now an object A can have a collection of objects B,
> but at the same time object B has to have a collection of objects A,
> effectively linking A and B tightly together. If you want to have object
> A to be part of a collection in an object C, you have to provide a
> collection in object B pointing to objects C .....
>
> Object B shouldn't have to know that it is part of a collection in an
> M:N scenario.
>
> The only testcase for that MtoN-issue is testMNLoading() in MtoNMapping
> which uses the Person-Project relationship, where Person has a
> collection of Projects and Project has a collection of Persons.
>
> I have assembled a testcase which should check the form of
> MtoN-relationships where the N-Class doesn't have a collection of
> M-Objects. Of course it fails right away, but it would be a starting
> point to analyze how to fix things.
>
> I have attached the following things:
>
> 1.) a method testMultipleMtoNRelations() which should go into the
>     MtoNMapping.java file
>
> 2.) the files Inventory.java and ShoppingCart.java which go into the same
> directory
>
> 3.) the mapping for both classes which has to be added to
> repository_junit.xml
>
> 4.) the create statement for the tables and indirection tables which has
> to go into db-setup.sql
>
> Cheers
>
> Georg
>

[OJB-developers] Re: MtoN-followup

[Georg S. <ge...@me...>]

Hi jacob,

Could you give me the basic reason for that requirement or please point me
to your discussion with Oleg (I missed that one :-) ).
Nevertheless I think that this is quite a big intrusion into the java code
and since all of the information needed is already in the
CollectionDescriptor of the M-side, I don't see a reason for doing it.

Cheers

Georg

[OJB-developers] Re: MtoN-followup

[Jakob B. <jbr...@ho...>]

hi georg,

this was a 'private' discussion, meaning we did not use the mailing-list.
btw. im working on solution to solve this problem...

jakob

----- Original Message -----
From: "Georg Schneider" <ge...@me...>
To: "Jakob Braeuchi" <jbr...@ho...>
Cc: <obj...@li...>
Sent: Thursday, June 06, 2002 3:24 PM
Subject: Re: MtoN-followup


> Hi jacob,
>
> Could you give me the basic reason for that requirement or please point me
> to your discussion with Oleg (I missed that one :-) ).
> Nevertheless I think that this is quite a big intrusion into the java code
> and since all of the information needed is already in the
> CollectionDescriptor of the M-side, I don't see a reason for doing it.
>
> Cheers
>
> Georg
>
>
>

Re: [OJB-developers] Re: MtoN-followup

[Oleg N. <on...@ib...>]

Hi Jacob and Georg,

It is convenient to have bidirectional relationship for OJB internals
(this makes things more uniform and simple),
but it may be inconvenient for user.
I propose the following trick: if there is no inverse relationship we
generate it automatically. We may even allow user to use it in query
conditions. For example "~rel" would mean inverse relation for "rel".
What do you think?

Oleg

Georg Schneider wrote:
> Hi jacob,

> Could you give me the basic reason for that requirement or please point me
> to your discussion with Oleg (I missed that one :-) ).
> Nevertheless I think that this is quite a big intrusion into the java code
> and since all of the information needed is already in the
> CollectionDescriptor of the M-side, I don't see a reason for doing it.

> Cheers

> Georg



> _______________________________________________________________

> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] Re: MtoN-followup

[Georg S. <ge...@me...>]

Hi Oleg,

You mean you would construct a CollectionDescriptor for the N-side and not
add it to the ClassDescriptor of the N-side?

Cheers

Georg

On Thu, 6 Jun 2002, Oleg Nitz wrote:

> Hi Jacob and Georg,
>
> It is convenient to have bidirectional relationship for OJB internals
> (this makes things more uniform and simple),
> but it may be inconvenient for user.
> I propose the following trick: if there is no inverse relationship we
> generate it automatically. We may even allow user to use it in query
> conditions. For example "~rel" would mean inverse relation for "rel".
> What do you think?
>
> Oleg
>
> Georg Schneider wrote:
> > Hi jacob,
>
> > Could you give me the basic reason for that requirement or please point me
> > to your discussion with Oleg (I missed that one :-) ).
> > Nevertheless I think that this is quite a big intrusion into the java code
> > and since all of the information needed is already in the
> > CollectionDescriptor of the M-side, I don't see a reason for doing it.
>
> > Cheers
>
> > Georg
>
>
>
> > _______________________________________________________________
>
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] MtoN-followup

[Jakob B. <jbr...@ho...>]

hi,

i'm currently working on a solution using the old m:n queries
(unidirectional).
i've sent some fixes to georg to test them.

jakob

----- Original Message -----
From: "Georg Schneider" <ge...@me...>
To: "Mahler Thomas" <tho...@it...>
Cc: <jbr...@ho...>; <obj...@li...>
Sent: Thursday, June 06, 2002 1:50 PM
Subject: [OJB-developers] MtoN-followup


> Hi Jacob and Thomas
>
> This is the follow-up to my previous mail talking about the
> M:N-Relationship issue:
>
> OK, the basic issue is, that an object should be able to form part of
> different collections. The basic example I give is that you could have
> an Inventory object which contains a list of Articles, and ShoppingCart
> objects which also contain a list of Articles.
> I don't think that this is a minor feature, but it is simply the way
> objects can be used in Java.
>
> Up to the last release this was possible, but now the entire MtoN-code
> has been changed. Now an object A can have a collection of objects B,
> but at the same time object B has to have a collection of objects A,
> effectively linking A and B tightly together. If you want to have object
> A to be part of a collection in an object C, you have to provide a
> collection in object B pointing to objects C .....
>
> Object B shouldn't have to know that it is part of a collection in an
> M:N scenario.
>
> The only testcase for that MtoN-issue is testMNLoading() in MtoNMapping
> which uses the Person-Project relationship, where Person has a
> collection of Projects and Project has a collection of Persons.
>
> I have assembled a testcase which should check the form of
> MtoN-relationships where the N-Class doesn't have a collection of
> M-Objects. Of course it fails right away, but it would be a starting
> point to analyze how to fix things.
>
> I have attached the following things:
>
> 1.) a method testMultipleMtoNRelations() which should go into the
>     MtoNMapping.java file
>
> 2.) the files Inventory.java and ShoppingCart.java which go into the same
> directory
>
> 3.) the mapping for both classes which has to be added to
> repository_junit.xml
>
> 4.) the create statement for the tables and indirection tables which has
> to go into db-setup.sql
>
> Cheers
>
> Georg
>