Markus,
I thought you were attempting to fix issue 702 which is validation for when a user attempts to change the PK value of an Entity. When I mentioned "updatable = false" I was talking about the case (the underlying column is non-updatable) where we shouldn't throw an exception even though the user has attempted to update the PK.
--Gordon
-----Original Message-----
From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
Markus Fuchs
Sent: Thursday, September 14, 2006 2:55 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: Fix for issue 702
Hi Gordon,
What did you mean by mentioning "updatable = false" then? I thought this
was about making sure that no "updatable = false" fields are included in
update statements, which could be done in the write phase.
Thanks!
-- markus.
Gordon Yorke wrote:
>Hello Markus,
> You are correct we should also check OneToOneMappings for PK updates as well. I do not think that any updates to updatability, insertability and nullability should be handled by this fix. That should be left for issue 699?
>--Gordon
>
>-----Original Message-----
>From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>Markus Fuchs
>Sent: Thursday, September 14, 2006 2:19 PM
>To: persistence_at_glassfish.dev.java.net
>Subject: Re: Fix for issue 702
>
>
>Hi Gordon,
>
>Sounds like a good idea. I agree that the write phase might a better
>place to implement this validation. I'll look into this option. One
>question:
>
>DirectToFieldMapping is responsible only for non-relationship fields.
>Shouldn't the updatability, insertability, nullability also be checked
>for the owning side of relationships, i.e. in ObjectReferenceMapping and
>CollectionMapping?
>
>Thanks for the review!
>
>-- markus.
>
>
>Gordon Yorke wrote:
>
>
>
>>Hello Markus,
>> The code looks good but it will only apply to the DeferredChangeDetectionPolicy. If any other policies are developed or used (say an active change detection policy that calcs changes as they are made) then this validation would not be applicable as well these changes do not really take updatable = false into account.
>> Perhaps a better spot for this validation would be within the write cycle (DirectToFieldMapping.writeFromObjectIntoRow()). Validation here, during the write cycle, would apply to any change detection policies and could take into account updatable = false? (ie. if the attribute was updated but the user has marked the column as not updatable )?
>> What do you think?
>>--Gordon
>>-----Original Message-----
>>From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>>Markus Fuchs
>>Sent: Wednesday, September 13, 2006 9:07 PM
>>To: Tom Ware
>>Cc: persistence_at_glassfish.dev.java.net
>>Subject: Fix for issue 702
>>
>>
>>Hi Tom,
>>
>>To address issue "702 - Can't update a primary key of a composite key",
>>I added validation preventing updates to primary key fields.
>>
>>I've changed DeferredChangeDetectionPolicy to call
>>DatabaseMapping.calculateValidatedChange instead of
>>DatabaseMapping.compareForChange directly.
>>DatabaseMapping.calculateValidatedChange calls compareForChange to
>>prepare the ChangeRecord for the field, and than does the validation, if
>>the ChangeRecord is not null (= the field has been set or updated). Any
>>updates to primary key fields are disallowed. Setting primary key fields
>>for inserts is allowed, of course! I added a ValidationException and
>>changed ValidationExceptionResource for that purpose.
>>
>>EntityManagerJUnitTestSuite now has two new tests:
>>
>>a) that the correct exception if thrown in case of a primary key update
>>b) that updating a primary key field with the same value is allowed
>>
>>The entity-persistence-tests pass on Oracle. Please do the code-review.
>>
>>Thank you!
>>
>>-- markus.
>>
>>
>>
>>
>>
>>
>>
>>