You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Joerg von Frantzius <jo...@artnology.com> on 2009/05/07 18:36:34 UTC
Detecting inconsistencies of mapped-by declarations?
Hi,
in the XML metadata, it is possible to have multiple FCO fields, e.g.
B.a1 and B.a2, with identical mapped-by pointing to the same field of
the same related class, e.g. A.b. In effect this would theoretically
mean that the FK should be shared among different associations in the
object model. I don't think that this does make much sense.
Also it is possible to declare two fields in two different classes, e.g.
B1.a and B2.a, with the identical mapped-by pointing to the same field
of the same related class, e.g. A.a. That would mean that in theory two
FKs would have to be created for the same column, pointing to different
tables. That neither seems to make sense to me.
Should the implementation throw an error in such situations, warning the
user of the erroneous metadata?
Regards,
Jörg
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
Erik Bengtson wrote:
>> Why would you want to have two different fields for the same
>> association? As far as I can see, it would always hold true that
>> b.a1==b.a2. You could express that in OCL in your UML, but in most cases
>> in the jdo metadata the above would be an error. You could still have
>> another getter getA2() returning the same field a1 if you really want
>> that behaviour implemented.
>>
>
> It's not the same association. There are two associations in here, and they
> are probably meant to be used exclusively.
>
If that's supposed to be two different associations, then they should
have distinct fields on both ends? You're not talking about n-ary
associations here, are you?
If not, then at least the UML doesn't allow different associations to
share ends. If you look at Figure "7.12 - Classes diagram of the Kernel
package" in UML2 superstructure 2.1.2 (07-11-02), you'll see that class
Association has a containment association to class Property that
includes its memberEnds, so a Property can belong only to one association.
>
>> In UML you'd have to write something like "for any b1 of type B1 and b2
>> of type B2: b1.a==b2.a" in OCL to express the above. Why should we
>> support implementing this using mapped-by if no database supports it?
>> Also, you can of course still implement this in other ways.
>>
>
> Why not? We can add one column that preserves the role name(example 1) of
> the association or the class name(example 2) that has the association
> instance.
>
That was unfortunately complete nonsense what I wrote there, please see
my own answer to my email. Talking about the UML2, it would rule out
this case as well. You simply cannot model the sharing of association
ends in UML2.
>
> I think we can raise a warning if the user tries to map such situations, but
> throwing an error would be a blocker for advanced usage.
>
I didn't understand yet what the purpose of that usage would be? How
would you express your intentions in UML2?
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
RE: Detecting inconsistencies of mapped-by declarations?
Posted by Erik Bengtson <er...@jpox.org>.
>Why would you want to have two different fields for the same
>association? As far as I can see, it would always hold true that
>b.a1==b.a2. You could express that in OCL in your UML, but in most cases
>in the jdo metadata the above would be an error. You could still have
>another getter getA2() returning the same field a1 if you really want
>that behaviour implemented.
It's not the same association. There are two associations in here, and they
are probably meant to be used exclusively.
>In UML you'd have to write something like "for any b1 of type B1 and b2
>of type B2: b1.a==b2.a" in OCL to express the above. Why should we
>support implementing this using mapped-by if no database supports it?
>Also, you can of course still implement this in other ways.
Why not? We can add one column that preserves the role name(example 1) of
the association or the class name(example 2) that has the association
instance.
I think we can raise a warning if the user tries to map such situations, but
throwing an error would be a blocker for advanced usage.
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
Erik Bengtson wrote:
>> in the XML metadata, it is possible to have multiple FCO fields, e.g.
>> B.a1 and B.a2, with identical mapped-by pointing to the same field of
>> the same related class, e.g. A.b. In effect this would theoretically
>> mean that the FK should be shared among different associations in the
>> object model. I don't think that this does make much sense.
>>
>
> It makes sense to me, because a1 and a2 are distinct associations, thus
> different roles.
>
Why would you want to have two different fields for the same
association? As far as I can see, it would always hold true that
b.a1==b.a2. You could express that in OCL in your UML, but in most cases
in the jdo metadata the above would be an error. You could still have
another getter getA2() returning the same field a1 if you really want
that behaviour implemented.
>
>> Also it is possible to declare two fields in two different classes, e.g.
>> B1.a and B2.a, with the identical mapped-by pointing to the same field
>> of the same related class, e.g. A.a. That would mean that in theory two
>> FKs would have to be created for the same column, pointing to different
>> tables. That neither seems to make sense to me.
>>
>
> It makes sense to me. Same as above.
>
> It's not common to handle these associations in relational databases, but
> very common when using UML.
>
In UML you'd have to write something like "for any b1 of type B1 and b2
of type B2: b1.a==b2.a" in OCL to express the above. Why should we
support implementing this using mapped-by if no database supports it?
Also, you can of course still implement this in other ways.
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
RE: Detecting inconsistencies of mapped-by declarations?
Posted by Erik Bengtson <er...@jpox.org>.
>in the XML metadata, it is possible to have multiple FCO fields, e.g.
>B.a1 and B.a2, with identical mapped-by pointing to the same field of
>the same related class, e.g. A.b. In effect this would theoretically
>mean that the FK should be shared among different associations in the
>object model. I don't think that this does make much sense.
It makes sense to me, because a1 and a2 are distinct associations, thus
different roles.
>Also it is possible to declare two fields in two different classes, e.g.
>B1.a and B2.a, with the identical mapped-by pointing to the same field
>of the same related class, e.g. A.a. That would mean that in theory two
>FKs would have to be created for the same column, pointing to different
>tables. That neither seems to make sense to me.
It makes sense to me. Same as above.
It's not common to handle these associations in relational databases, but
very common when using UML.
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
Andy Jefferson wrote:
>> Should the implementation throw an error in such situations, warning the
>> user of the erroneous metadata?
>>
>
> Shared FK relations are a perfectly valid thing to have IMHO
> http://www.datanucleus.org/products/accessplatform_1_1/jdo/orm/one_to_many_collection.html#shared_fk
> You could have the same as that example with 1-1 and a discriminator for
> determining the relation.
>
Sorry I had put it too general: what I really had in mind is that an FK
(value) in the same table row would be shared by two different
associations in the object model.
Since that datanucleus extension is about an additional
relation-discriminator to discern the two associations in a join table,
this is not the case in your example. I take it that this only works for
join tables, and not for single-FK mapping?
> The place of an ORM spec is to standardise particular relation types, not to
> prevent other ones.
>
>
>
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andy,
On May 7, 2009, at 9:47 AM, Andy Jefferson wrote:
>> Should the implementation throw an error in such situations,
>> warning the
>> user of the erroneous metadata?
>
> Shared FK relations are a perfectly valid thing to have IMHO
> http://www.datanucleus.org/products/accessplatform_1_1/jdo/orm/one_to_many_collection.html#shared_fk
> You could have the same as that example with 1-1 and a discriminator
> for
> determining the relation.
In the absence of the datanucleus extension, it's an error, right?
i.e., there's no standard way to implement this.
Craig
>
>
> The place of an ORM spec is to standardise particular relation
> types, not to
> prevent other ones.
>
>
> --
> Andy (DataNucleus - http://www.datanucleus.org)
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Andy Jefferson <an...@datanucleus.org>.
> Should the implementation throw an error in such situations, warning the
> user of the erroneous metadata?
Shared FK relations are a perfectly valid thing to have IMHO
http://www.datanucleus.org/products/accessplatform_1_1/jdo/orm/one_to_many_collection.html#shared_fk
You could have the same as that example with 1-1 and a discriminator for
determining the relation.
The place of an ORM spec is to standardise particular relation types, not to
prevent other ones.
--
Andy (DataNucleus - http://www.datanucleus.org)
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
Andy Jefferson wrote:
>> Needless to say that supporting this rare corner case would make the
>> implementation much more complex, in particular with respect to
>> bidirectional management.
>>
>> Maybe we could rule out the use of mapped-by in this case?
>>
>
> -1
>
> Just because you don't have need for that case is no reason to prohibit it.
> Heck, the JPA crowd were calling Collection<String> as "exotic" and "corner
> case" some time back. Nice. Also, JDO is for all datastores not just RDBMS,
> and while you may just use RDBMS, there are many other datastores where this
> is very reasonable.
> The whole point of persistence specification is to capture requirements and
> cater for what people want, not to prohibit when something seems difficult.
>
I only tried to argue from a point of view of what I'd find sane object
modeling. Some say the UML2 is over-complex in trying to cover
everything, but not even the UML2 covers this, nor does e.g. the Eclipse
Modeling Framework.
What you have here is either two associations sharing one end, or a
single association connecting more than two classes (without it being
n-ary). Whichever way you see it, that's not an association anymore, at
least not from an OOA/D perspective.
Sticking to agreed OOA/D concepts certainly does have its merits, be it
the concept of the "association" or that of "genericity" ;)
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Andy Jefferson <an...@datanucleus.org>.
> Needless to say that supporting this rare corner case would make the
> implementation much more complex, in particular with respect to
> bidirectional management.
>
> Maybe we could rule out the use of mapped-by in this case?
-1
Just because you don't have need for that case is no reason to prohibit it.
Heck, the JPA crowd were calling Collection<String> as "exotic" and "corner
case" some time back. Nice. Also, JDO is for all datastores not just RDBMS,
and while you may just use RDBMS, there are many other datastores where this
is very reasonable.
The whole point of persistence specification is to capture requirements and
cater for what people want, not to prohibit when something seems difficult.
--
Andy (DataNucleus - http://www.datanucleus.org)
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
To continue discussing this with myself a bit:
Andy pointed out to me one case where we could end up with multiple
fields being associated to the same single field via mapped-by. That's
when we have a collection field with element-type supplying a
comma-separated list of possible elements, and that same field having a
mapped-by annotation.
To me this seems somewhat exotic, and I wouldn't know how to model that
e.g. in the UML neither. Also, it would only work if the corresponding
fields in the element classes were all named the same, since mapped-by
can have only a single value. So if we really wanted to fully support
this, then mapped-by would have to be extended to list pairs of target
class name and field name.
Needless to say that supporting this rare corner case would make the
implementation much more complex, in particular with respect to
bidirectional management.
Maybe we could rule out the use of mapped-by in this case?
Joerg von Frantzius wrote:
> Hi Craig,
>
> thanks for your answer. I still wonder a bit about implications of
> mapped-by when combined with interfaces.
>
> Suppose we have class AImpl with a field "b" of type interface B, with B
> having a property "a" of type AImpl, and two implementations BImpl1 and
> BImpl2 of B, in other words:
>
> class A { B b; }
> interface B { A getA(); }
> class BImpl1 implements B { private A a; ...}
> class BImpl2 implements B { private A a; ...}
>
> Now if either B.a or Bimpl1.a or BImpl2.a were annotated with
> mapped-by="b", that would be problem 2) again where multiple FK
> constraints on the same column would be pointing to different tables. Right?
>
> The basic question for me is whether in the implementation,
> AbstractMemberMetaData (the representation of field metadata) could be
> associated with multiple other AbstractMemberData objects by means of
> mapped-by. I'd think that two AbstractMemberMetaData objects can be
> related only One-To-One by means of mapped-by.
>
> Regards,
> Jörg
>
> Craig L Russell wrote:
>
>> Hi Jörg,
>>
>> On May 7, 2009, at 9:36 AM, Joerg von Frantzius wrote:
>>
>>
>>> Hi,
>>>
>>> in the XML metadata, it is possible to have multiple FCO fields, e.g.
>>> B.a1 and B.a2, with identical mapped-by pointing to the same field of
>>> the same related class, e.g. A.b. In effect this would theoretically
>>> mean that the FK should be shared among different associations in the
>>> object model. I don't think that this does make much sense.
>>>
>> I agree.
>>
>>> Also it is possible to declare two fields in two different classes, e.g.
>>> B1.a and B2.a, with the identical mapped-by pointing to the same field
>>> of the same related class, e.g. A.a. That would mean that in theory two
>>> FKs would have to be created for the same column, pointing to different
>>> tables. That neither seems to make sense to me.
>>>
>> I agree.
>>
>>> Should the implementation throw an error in such situations, warning the
>>> user of the erroneous metadata?
>>>
>> Yes.
>>
>> Craig
>>
>>> Regards,
>>> Jörg
>>>
>>> --
>>> ____________________________________________________________________
>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>>> UST-Id. DE 217652550
>>>
>>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
>
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Joerg von Frantzius <jo...@artnology.com>.
Hi Craig,
thanks for your answer. I still wonder a bit about implications of
mapped-by when combined with interfaces.
Suppose we have class AImpl with a field "b" of type interface B, with B
having a property "a" of type AImpl, and two implementations BImpl1 and
BImpl2 of B, in other words:
class A { B b; }
interface B { A getA(); }
class BImpl1 implements B { private A a; ...}
class BImpl2 implements B { private A a; ...}
Now if either B.a or Bimpl1.a or BImpl2.a were annotated with
mapped-by="b", that would be problem 2) again where multiple FK
constraints on the same column would be pointing to different tables. Right?
The basic question for me is whether in the implementation,
AbstractMemberMetaData (the representation of field metadata) could be
associated with multiple other AbstractMemberData objects by means of
mapped-by. I'd think that two AbstractMemberMetaData objects can be
related only One-To-One by means of mapped-by.
Regards,
Jörg
Craig L Russell wrote:
> Hi Jörg,
>
> On May 7, 2009, at 9:36 AM, Joerg von Frantzius wrote:
>
>> Hi,
>>
>> in the XML metadata, it is possible to have multiple FCO fields, e.g.
>> B.a1 and B.a2, with identical mapped-by pointing to the same field of
>> the same related class, e.g. A.b. In effect this would theoretically
>> mean that the FK should be shared among different associations in the
>> object model. I don't think that this does make much sense.
>
> I agree.
>>
>>
>> Also it is possible to declare two fields in two different classes, e.g.
>> B1.a and B2.a, with the identical mapped-by pointing to the same field
>> of the same related class, e.g. A.a. That would mean that in theory two
>> FKs would have to be created for the same column, pointing to different
>> tables. That neither seems to make sense to me.
>
> I agree.
>>
>>
>> Should the implementation throw an error in such situations, warning the
>> user of the erroneous metadata?
>
> Yes.
>
> Craig
>>
>>
>> Regards,
>> Jörg
>>
>> --
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>> UST-Id. DE 217652550
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Re: Detecting inconsistencies of mapped-by declarations?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jörg,
On May 7, 2009, at 9:36 AM, Joerg von Frantzius wrote:
> Hi,
>
> in the XML metadata, it is possible to have multiple FCO fields, e.g.
> B.a1 and B.a2, with identical mapped-by pointing to the same field of
> the same related class, e.g. A.b. In effect this would theoretically
> mean that the FK should be shared among different associations in the
> object model. I don't think that this does make much sense.
I agree.
>
>
> Also it is possible to declare two fields in two different classes,
> e.g.
> B1.a and B2.a, with the identical mapped-by pointing to the same field
> of the same related class, e.g. A.a. That would mean that in theory
> two
> FKs would have to be created for the same column, pointing to
> different
> tables. That neither seems to make sense to me.
I agree.
>
>
> Should the implementation throw an error in such situations, warning
> the
> user of the erroneous metadata?
Yes.
Craig
>
>
> Regards,
> Jörg
>
> --
> ____________________________________________________________________
> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
> UST-Id. DE 217652550
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!