[jira] [Commented] (CAY-1896) Flattened attributes don't work with optimistic locking on

["John Huss (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAY-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888291#comment-13888291 ] 

John Huss commented on CAY-1896:
--------------------------------

There seems to be several problems with flattened attributes actually besides just optimistic locking.  But I've attached a small patch that fixes it the simple way by just removing the locking for flattened attributes.

But to address the locking - what is the desired behavior if you lock on a flattened attribute?  I suppose it would mean that the update statement would have to include an EXISTS expression to check the flattened entity, for example:

UPDATE Painting SET name = "abc" 
WHERE painting_id=1 
AND painting_name="123" 
AND EXISTS(SELECT * FROM Artist WHERE artist_id=1 AND artist_name="Pablo")

Where artist_name is source of the flattened attribute that has locking turned on.  This implicitly locks on the "artist" relationship as well since it's required in order to check the artist name.

But what about cases where the flattened attribute is updated?  Since it is updating a separate table what attributes should be locked on that table?  Since there is no ObjEntity for the flattened table there is no information directly available about what to lock on other than the flattened attributes themselves.  So you could lock on all the flattened attributes with the same source.  Or you could cheat and lookup the ObjEntity for that related table (Artist) if available and steal the locking info from there.

My personal take is that IF flattened attributes are locked then you probably want this behavior:
1) For the ObjEntity that contains the flattened attribute (Painting) - add EXISTS checks to all the updates to check the flattened attributes.  That's what the locking means after all.
2) For the target DbEntity that actually contains the target attribute (Artist) - when the flattened table is updated add checks for all the columns that have been flattened into the master entity and locked.  So if you flatten Artist's "name" and dateOfBirth into Painting and lock them, then if you update those attributes via Painting, then the locking on them should be checked.  Other attributes in Artist (not Painting) would be ignored since we don't really know whether to lock on them or not.

> Flattened attributes don't work with optimistic locking on
> ----------------------------------------------------------
>
>                 Key: CAY-1896
>                 URL: https://issues.apache.org/jira/browse/CAY-1896
>             Project: Cayenne
>          Issue Type: Bug
>          Components: Core Library
>    Affects Versions: 3.2M1
>            Reporter: John Huss
>         Attachments: 0001-Fix-flattened-attributes.patch, cayenne-mvn-snippet.zip
>
>
> Flattened attributes can not be modified and saved with if you have optimistic locking turned on for a to-one relationship in the same entity with the flattened attribute.  
> For example, say you have Artist and Painting and a flattened attribute "artistName" on Painting and you set this to a new value.  And you also have optimistic locking on the Painting.artist relationship.  It tries to generate SQL for the flattened object (Artist) that includes the to-one relationship foreign key from the source object (Painting) and fails because the column is not found:
> UPDATE ARTIST SET NAME = ? WHERE ID IS NULL AND ARTIST_ID = ?
> Column 'ARTIST_ID' is either not in any table in the FROM list...
> A minimal example is attached.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)