db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Detecting inconsistencies of mapped-by declarations?
Date Fri, 08 May 2009 12:59:59 GMT
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


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message