Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Code review please for bug 510143.

Thanks Heath for looking into this issue and working on a fix! As far as EclipseLink documentation, I see that for EclipseLink/UserGuide/JPA/Basic_JPA_Development/Entities/Ids/Id, is states: "The id of a persistent object instance must never be changed and cannot be updated". To me that seems to imply "updatable=false", otherwise it could b assumed that merging the persistent object would legally update the PK. So I agree it doesnt make much sense for EclipseLink to throw this exception if the Entity is trying to explicitly define both "insertable=false" and "updatable=false" on @Column. However, I am unsure as to how this plays with EclipseLink's @ReadOnly annotation. Perhaps someone else knows more about EclipseLink's implementation specifically.


On Thu, Jan 19, 2017 at 3:05 PM, Heath Thomann <jpaheath@xxxxxxxxx> wrote:
HI!  I created a bug (510143) for an issue with @Column(insertable=false,updatable=false) on an @Id.  There seems to be tests for insertable=false,updatable=false on a non-PK field, but it seems insertable=false,updatable=false on an @Id has never been tested.

In addition to reviewing my fix, I wonder if info (documentation) is needed on what it means to be "read only" in EclipseLink.  That is, it seems that EL has a @ReadOnly annotation, it also has a hint, others?  Internally in the EL code, I see variables and comments mentioning "read only".  In DatabaseField for instance, there is the following method that test exactly for 'insertable=false,updatable=false' and deems that as read only:

     * Returns true is this database field should be read only.
    public boolean isReadOnly() {
        return (! isUpdatable && ! isInsertable);

So for the newbie like me, "read only" seems confusing and overloaded, not to mention there is no concept of "read only" in the spec.  :)

Furthermore, I have to wonder if EL simply assumes that 'insertable=false,updatable=false' on an @Id is irrelevant, and as such doesn't really handle or expect it?  I agree that by its nature a PK is "read only" once set.  But from a user point of view I think they'd be inclined to add 'insertable=false,updatable=false' to strictly enforce the fact that the entity can't be created, only read from the DB.  I can't see anything in the spec making this illegal and my test runs fine on both OpenJPA and Hibernate.  :-)  As an aside, I have to wonder if the handling of this was influenced by the comments in the Pro JPA 2 book, second edition, page 282, where it talks about a "read only" entity and gives an example of 'insertable=false,updatable=false' on a non PK field.  For a PK field the book states "We don't need to worry about the identifier being modified, because it is illegal to modify identifiers".

Any thoughts on this would be greatly appreciated.


Heath Thomann

eclipselink-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top