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.
>>
>>
>>
>>
>>