cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Huss (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAY-1896) Flattened attributes don't work with optimistic locking on
Date Wed, 24 Jun 2015 19:05:05 GMT

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

John Huss edited comment on CAY-1896 at 6/24/15 7:04 PM:
---------------------------------------------------------

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


was (Author: johnthuss):
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.2.M1
>            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.3.4#6332)

Mime
View raw message