[ 
https://issues.apache.org/jira/browse/IGNITE-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov reassigned IGNITE-4363:
---------------------------------------

    Assignee: Alexander Paschenko  (was: Vladimir Ozerov)

[~al.psc],
It seems that this fix conflicts with some other SQL change related to 
properties. Could you please re-merge from {{master}} and resolve the conflict?

> Inner properties mutation broken in SQL UPDATE
> ----------------------------------------------
>
>                 Key: IGNITE-4363
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4363
>             Project: Ignite
>          Issue Type: Bug
>          Components: binary, SQL
>    Affects Versions: 1.8
>            Reporter: Alexander Paschenko
>            Assignee: Alexander Paschenko
>             Fix For: 1.9
>
>
> Discovered in course of working on IGNITE-4340.
> Say, we have following type for cache values
> {code:java}
> static final class AllTypes implements Serializable {
>         /**
>          * Data Long.
>          */
>         @QuerySqlField
>         Long longCol;
>         /**
>          * Inner type object.
>          */
>         @QuerySqlField
>         InnerType innerTypeCol;
>         /** */
>         static final class InnerType implements Serializable {
>             /** */
>             @QuerySqlField
>             Long innerLongCol;
>             /** */
>             @QuerySqlField
>             String innerStrCol;
>        }
> }
> {code}
> Queries like this fail for both optimized and binary marshaller:
> {code:sql}
> UPDATE AllTypes set innerLongCol = ?
> {code}
> For optimized, current DML implementation mutates existing inner property 
> thus confusing DML statements re-run logic (query re-runs because engine sees 
> value as concurrently modified, though the only change is its own, and 
> ultimately fails). The solution is to clone inner objects and set new 
> property values on them because we need to have old value pristine.
> For binary, current DML implementation does not honor properties hierarchy 
> and, for above example, just sets {{innerLongCol}} field on {{AllTypes}} 
> binary object and not its child {{InnerType}} object. Thus, index will be 
> updated and SELECTs for that column will return correct value for that field, 
> but inner state of target property {{innerTypeCol}} does not change, and 
> {{AllTypes}} object gets its own odd field {{innerLongCol}} which it does not 
> know how to do with (no metadata about it in type descriptor).
> The patch for both problems is ready and lying on my shelf waiting for 1.8 
> release to happen to be applied. Then this will ultimately be fixed with the 
> rest of known problems/improvements (Jira issues for them will follow).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to