You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cayenne.apache.org by "Andrus Adamchik (JIRA)" <ji...@apache.org> on 2019/07/09 14:59:00 UTC

[jira] [Comment Edited] (CAY-2019) Optimistic locking always fails on CRYPTO columns

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

Andrus Adamchik edited comment on CAY-2019 at 7/9/19 2:58 PM:
--------------------------------------------------------------

Since "cayenne-crypto" is an extension, the Modeler can't assume anything about it (unless we create a matching optional Modeler extension). 

In addition to my notes on https://github.com/apache/cayenne/pull/397 , I think quietly turning off optimistic locking is also not a good solution. It may lead to unexpected behavior.

So perhaps we just need to ensure that Cayenne stack stops leaking plaintext when generating optimistic locking code, print a warning when somebody tries to lock such a column, but otherwise let the user deal with it?




was (Author: andrus):
Since "cayenne-crypto" is an extension, the Modeler can't assume anything about it (unless we create a matching optional Modeler extension). 

Perhaps we just need to ensure that Cayenne stack stops leaking plaintext when generating optimistic locking code, but otherwise let the user deal with it?

Also see my notes on https://github.com/apache/cayenne/pull/397

> Optimistic locking always fails on CRYPTO columns
> -------------------------------------------------
>
>                 Key: CAY-2019
>                 URL: https://issues.apache.org/jira/browse/CAY-2019
>             Project: Cayenne
>          Issue Type: Bug
>          Components: Core Library
>    Affects Versions: 4.0.M2
>            Reporter: John Huss
>            Assignee: John Huss
>            Priority: Minor
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> If you have optimistic locking turned on for columns that are configured to be encrypted (named CRYPTO_*) then updates to those rows will always fail because it uses the unencrypted value to check the optimistic locking, ie. WHERE encryptedColumn = <unencryptedValue>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)