Gordon, Markus,
I checked with Linda, and the spec *does not allow* @Id annotation
in an @Embeddable class:
"9.1.8 Id Annotation
The Id annotation may be applied in an entity or mapped superclass."
Which means that if we do, it's a bug.
regards,
-marina
Marina Vatkina wrote On 09/18/06 12:11,:
> Hello Gordon,
>
> The spec says (9.1.14):
>
> "The EmbeddedId annotation is applied to a persistent field or property of an
> entity class or mapped superclass to denote a composite primary key that is an
> embeddable class."
>
> It doesn't say "can be part of". Will such embeddable implement equals and
> hashcode based only on the pk fields? If not, why won't they be part of the pk?
> If yes, can it cause any other unexpected problems? Will such behavior
> be portable?
>
> thanks,
> -marina
>
>
> Gordon Yorke wrote On 09/18/06 11:31,:
>
>>Hello Markus,
>> Yes, only part of an embedded object can be the PK. I am quite sure
>>that there is nothing in TopLink or the specification that prevents
>>additional mappings in the Embeddable.
>> In the case of an additional change in the embedded object that did
>>not alter the PK there would be a change record for the aggregate obejct
>>that included a change record for the non-pk mapping. The
>>AggregateObjectMapping would most likely still be flagged as a PK mapping.
>>
>>--Gordon
>>
>> -----Original Message-----
>> *From:* Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]*On Behalf
>> Of *Markus Fuchs
>> *Sent:* Monday, September 18, 2006 2:22 PM
>> *To:* persistence_at_glassfish.dev.java.net
>> *Subject:* Re: Fix for issue 702
>>
>> Hi Gordon,
>>
>> I've moved the validation into AbstractDirectMapping and
>> OneToOneMapping. Please find some questions below!
>>
>> Gordon Yorke wrote:
>>
>>
>>>Hello Markus,
>>> The code changes look good. I know you asked about the AggregateObjectMapping before but now that I think about it I don't think we should include it. In TopLink the AggregateObjectMapping can be part of the PK mappings even if only a component of the AggregateObject is a PK mapping.
>>
>> What do you mean by component? Is it that only part of the embedded
>> object is part of the PK?
>>
>>
>>>Your current check would throw an exception even if the values in the Aggregate Object (Embeddable) did not change.
>>
>> Why is that? If there is a change record, there was an update, correct?
>>
>>
>>>The underlying DirectMapping in the Aggregate object should still be validated by the current code if the PK has changed so the PK would continue to be validated even if the code was removed from AggregateObjectMapping.
>>>
>>
>> Makes sense!
>>
>> Thanks,
>>
>> -- markus.
>>
>>
>>>--Gordon
>>>
>>>-----Original Message-----
>>>From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>>>Markus Fuchs
>>>Sent: Friday, September 15, 2006 8:09 PM
>>>To: persistence_at_glassfish.dev.java.net
>>>Subject: Re: Fix for issue 702
>>>
>>>
>>>Hi Gordon,
>>>
>>>The pk update validation is now implemented in
>>>DatabaseMapping.writeFromObjectIntoRowWithChangeRecord(), and is called
>>
>>>from the derived classes AbstractDirectMapping, OneToOneMapping, and
>>
>>>AggregateObjectMapping. The classes ValidationException and
>>>ValidationExceptionResource haven't changed. I also added one more test
>>>for overlapping primary/foreign keys to EntityManagerJUnitTestSuite.
>>>
>>>The JUnit tests on Oracle and JavaDB are successful. What do you think?
>>>
>>>Thanks!
>>>
>>>-- markus.
>>>
>>>Gordon Yorke wrote:
>>>
>>>
>>>
>>>
>>>>Actually I wasn't precise enough. The actual method would be writeFromObjectIntoRowWithChangeRecord(), If not changeRecord.getOwner().isNew() then you must have an update to this attribute and if this.isPrimaryKeyMapping() then you have an error case. There is no need to have the old value to validate that the error occured the fact that the method is called indicates the mapping was updated.
>>>>--Gordon
>>>>
>>>>-----Original Message-----
>>>>From: Markus.Fuchs_at_Sun.COM [mailto:Markus.Fuchs_at_Sun.COM]On Behalf Of
>>>>Markus Fuchs
>>>>Sent: Friday, September 15, 2006 2:22 PM
>>>>To: persistence_at_glassfish.dev.java.net
>>>>Subject: Re: Fix for issue 702
>>>>
>>>>
>>>>Hi Gordon,
>>>>
>>>>Thinking more about adding the pk update validation in the write phase,
>>>>I see two problems:
>>>>
>>>>* How do I know what kind of operation
>>>>DirectToFieldMapping.writeFromObjectIntoRow() is called for? I.e. insert
>>>>or update (or even delete?)?
>>>>* Do I have access to the previous field value at this point, to compare
>>>>new and old value?
>>>>
>>>>Thank you!
>>>>
>>>>-- 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>