Not necessarily - see e.g. issue 867
(
https://glassfish.dev.java.net/issues/show_bug.cgi?id=867).
We can document that updates of entities that are not mapped to both tables
will fail, but if this is the case, how delete will not be affected?
Also, if such fields/properties are marked as read-only, no new rows can be
added to a secondary table, which is probably not the case.
thanks,
-marina
Gordon Yorke wrote:
> This functionality is advanced and not easily found by users. It would not
> be used without some 'hand-holding' of the customer in which case they would
> be instructed to make those mappings read-only. TopLink has no logic to
> detect this altered secondary table configuration and raise exceptions if the
> user is not using it appropriately. If the user is using these advances
> features then it is presumed the user has the technical ability to determine
> appropriate behaviour for their data and model. Delete behaviour would not be
> affected. --Gordon
>
> -----Original Message----- From: Marina.Vatkina_at_Sun.COM
> [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of Marina Vatkina Sent: Thursday,
> August 03, 2006 3:35 PM To: persistence_at_glassfish.dev.java.net Subject: Re:
> Outer joins for secondary tables?
>
>
> Hello Gordon,
>
> Will TopLink throw an exception if the user changes such entity? Or will it
> allow the database to win (i.e. it'll update successfully only those entities
> that have rows in both tables)? How about a delete?
>
> thanks, -marina
>
> Gordon Yorke wrote:
>
>> Hello Markus, This customization is both in TopLink and TopLink Essentials.
>> It does require use of TopLink API directly and is not exposed through the
>> JPA. It is the user's responsibility to either treat the class as
>> readonly or mark all of the mappings read-only (updatable, insertable =
>> false in JPA). The best way to map this relationship is as a OneToOne.
>>
>> --Gordon
>>
>> -----Original Message----- From: Markus.Fuchs_at_Sun.COM
>> [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs Sent: Thursday,
>> August 03, 2006 2:14 PM To: Gordon Yorke Cc:
>> persistence_at_glassfish.dev.java.net Subject: Re: Outer joins for secondary
>> tables?
>>
>>
>> [including a broader audience]
>>
>> Hi Gordon,
>>
>> Thanks for your information! I have a couple of further questions:
>>
>> Gordon Yorke wrote:
>>
>>
>>
>>> Hello Markus, In TopLink a user can customize the
>>> MultipleTableJoinExpression in the DescriptorQueryManager. TopLink uses
>>> this expression when joining, updating this expression to use outer joins
>>> will cause TopLink to use outerjoins for secondary tables.
>>>
>>>
>>>
>>
>> Is this customization a TopLink product feature? I understand it is not
>> part of TopLink-Essentials.
>>
>>
>>
>>> This method, however, will only work for read-only objects as TopLink
>>> will be unable to update any secondary fields for objects that did not
>>> have a row in the secondary table. TopLink has no way of determining if
>>> the row was there once the object was built. Having this functionality
>>> would be a very large undertaking and would proportionally be of little
>>> value.
>>>
>>>
>>>
>>
>> Does customizing the MultipleTableJoinExpression make the entity read-only
>> automatically or is it the user's responsibility to treat that class as
>> read-only? If the class is read-only automatically, would it be possible to
>> treat only the fields actually mapped to the secondary table as read-only?
>> In a JPA context, would it be sufficient to mark the secondary table fields
>> "updatable=false"?
>>
>> Thanks!
>>
>> -- markus.
>>
>>
>>
>>> This sort of relationship should be mapped as an OneToOne.
>>>
>>> --Gordon
>>>
>>> -----Original Message----- From: Markus.Fuchs_at_Sun.COM
>>> [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of Markus Fuchs Sent: Wednesday,
>>> August 02, 2006 7:27 PM To: Tom Ware; Gordon Yorke Subject: Outer joins
>>> for secondary tables?
>>>
>>>
>>> Hi Tom, Gordon,
>>>
>>> I remember from one telephone meeting that TopLink can be switched
>>
>>> from generating inner joins for secondary tables to outer
>>
>>> joins.
>>>
>>> Looking into the code, I couldn't find such option. What am I missing? I
>>> couldn't even find an indicator in ClassDescriptor like
>>> "hasSecondaryTableMapping()". Is it possible to assume that the class has
>>> secondary table mappings, that if
>>> ClassDescriptor#additionalTablePrimaryKeyField != null?
>>>
>>> Thanks so much,
>>>
>>> -- markus.
>>>
>>>
>>>
>>>