[
https://issues.apache.org/jira/browse/IGNITE-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4363:
----------------------------------------
Description:
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).
was:
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}
D
> 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.8
>
>
> 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.4#6332)
