Markus, Gordon,
I think that PK update should be disallowed if it's an actual update (i.e.
setting an overlapping relationship that does not actually change anything,
should be OK).
thanks,
-marina
Markus Fuchs wrote:
> Hi Gordon,
>
> I agree to with you. Some tests failed, because with the validation for
> insertable=false the insert of PhoneNumber fails, as the id column is
> annotated inserable=false.
>
> I'd still like to implement the PK update validation, addressing issue
> 702. What do you think?
>
> Thanks,
>
> -- markus.
>
> Gordon Yorke wrote:
>
>> Markus,
>> Having the column not appear in the SQL is exactly what the user
>> should expect, that is what the specification very clearly states
>> should happen. The column should be treated as read-only. Throwing
>> an exception would not be expected by the user as it is not mentioned
>> or suggested in the specification. In the case of
>> PhoneNumber.java the insertable/updatable settings should not be
>> moved. The JPA specifcation places the requirement that all Entities
>> have an @Basic mapping that maps to the PK class but in many cases (as
>> with the PhoneNumber tables) the PK is the foreign key and as such is
>> owned and is derived from the related object. It is the "owner"
>> relationship that provides the PK for this class. The @Basic mapping
>> is there only to satisfy the PK requirement of the specification, and
>> many users will not want to maintain this made up attribute.
>> It is not clear why your proposed fix would cause these tests to
>> fail anyway?
>> --Gordon
>>
>> -----Original Message-----
>> From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>> Markus Fuchs
>> Sent: Tuesday, September 12, 2006 1:34 PM
>> To: persistence_at_glassfish.dev.java.net
>> Subject: Re: [Fwd: Fix for issue 699 and 702]
>>
>>
>> Hi Gordon,
>>
>> The spec says about insertable:
>>
>> insertable (Optional) Whether the column is included in
>> SQL INSERT statements generated by the persistence
>> provider.
>>
>> This sounds like we *should* validate that the field mapped to this
>> column is not set by the user. Setting the field and the column isn't
>> included in the insert statement, is probably not what the user expects.
>> We should also prevent PK updates.
>>
>> What do you think about the insertable=false, updatable=false annotation
>> on the "id" field in PhoneNumber.java? Shall we move this annotation to
>> the "owner" field? To indicate an overlapping PK/FK situation, the
>> relationship field should be annotated insertable=false,
>> updatable=false, not the primary key field.
>>
>> Thanks!
>>
>> -- markus.
>>
>> Gordon Yorke wrote:
>>
>>
>>
>>> Hello Markus,
>>> I don't think updatable, insertable settings should be validated.
>>> The specification explicitly states that these settings control what
>>> columns should be include in the SQL statements. These values should
>>> alter what TopLink writes to the database but forcing validation on
>>> the user restricts usage and would be counter to the specification.
>>> --Gordon
>>>
>>> -----Original Message-----
>>> From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>>> Markus Fuchs
>>> Sent: Monday, September 11, 2006 9:05 PM
>>> To: Tom Ware
>>> Cc: persistence_at_glassfish.dev.java.net
>>> Subject: [Fwd: Fix for issue 699 and 702]
>>>
>>>
>>> Resending, copying the persistence alias.
>>>
>>> -- markus.
>>>
>>>
>>>
>>>