Ignite 2.3: troubles with key-value APIs in the cluster configured with DDL

[dmagda]

Folks,

After we added CACHE_NAME, KEY_TYPE and VALUE_TYPE parameters [1] to CREATE TABLE syntax for 2.3, I’ve returned to a simple demo application [2] that aims to show how to use key-value, compute, service grid APIs in the cluster fully configured with DDL.

So, what was done and works:
* started the cluster with this config [3] (built binary from 2.3 branch).
* configured the cluster and preloaded data using this SQL script [4] fed to SQLLine tool.
* double checked that Java SQL APIs are workable.[5]
* could get a value with the key of BinaryObject type! [6] Something we didn’t support in 2.2.

But then got stuck with the following:
* failed to deserialize BinaryObject value to City type [7]. Just classical "class org.apache.ignite.binary.BinaryInvalidTypeException: City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
* failed to implement hashCode for CityKey for non binary key-val access. Thought I could setup BinaryArrayIdentityResolver for CityKey type to address the issue but we removed resolvers from the public configuration.
*  as a Java developer I was forced to name at least CityKey’s affinity field [9] in the way it's named in CREATE TABLE command [2]. Not a blocker but a big usability issue. Can we have case insensitive policy for fields names?

Vladimir, Alex P., will highly appreciate if you look at this before the release and help to overcome the issues I’m facing.

[1] https://apacheignite-sql.readme.io/docs/create-table#section-parameters
[2] https://github.com/dmagda/ignite_world_demo
[3] https://github.com/dmagda/ignite_world_demo/blob/master/config/ignite-config.xml
[4] https://github.com/dmagda/ignite_world_demo/blob/master/ignite_world.sql
[5] https://github.com/dmagda/ignite_world_demo/tree/master/src/main/java/demo/sql
[6] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L83
[7] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L86
[8] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/model/CityKey.java#L44
[9] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/model/CityKey.java#L14


—
Denis

[dmagda]

> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
>
> * failed to deserialize BinaryObject value to City type [7]. Just classical "class org.apache.ignite.binary.BinaryInvalidTypeException: City" caused by "Caused by: java.lang.ClassNotFoundException: City”.


Recalled that this should be caused by the fact that all the data was inserted with DML (cache.put(key, BinaryObjects)) and there was no single cache.put(key, new City()) that would register City class. Guess we need to add an API that forces classes registration from the app side or something more efficient.

—
Denis

[Vladimir Ozerov]

Denis,

SQL <-> key-Val transparency is complex thing, especially if you work with
real Java classes instead of binary objects.

We will try to improve something in 2.4, but do not expect great usability
here. There is always be some pain in such scenarios.

сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:

>
> > On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
> >
> > * failed to deserialize BinaryObject value to City type [7]. Just
> classical "class org.apache.ignite.binary.BinaryInvalidTypeException: City"
> caused by "Caused by: java.lang.ClassNotFoundException: City”.
>
>
> Recalled that this should be caused by the fact that all the data was
> inserted with DML (cache.put(key, BinaryObjects)) and there was no single
> cache.put(key, new City()) that would register City class. Guess we need to
> add an API that forces classes registration from the app side or something
> more efficient.
>
> —
> Denis

[Vladimir Ozerov]

Denis,

Now more detailed answer:

1) It is expected that "City" class is not be found. You should set
key/value type names to fully-qualified class name to make it work.
Improvements: docs
2) There is no need to implement hash code. Why did you do this?
3) We will not have case-insensitive policy, SQL databases doesn't work
this way. In order to preserve case you should define column name in quotes.

On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Denis,
>
> SQL <-> key-Val transparency is complex thing, especially if you work with
> real Java classes instead of binary objects.
>
> We will try to improve something in 2.4, but do not expect great usability
> here. There is always be some pain in such scenarios.
>
> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
>
>>
>> > On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
>> >
>> > * failed to deserialize BinaryObject value to City type [7]. Just
>> classical "class org.apache.ignite.binary.BinaryInvalidTypeException:
>> City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
>>
>>
>> Recalled that this should be caused by the fact that all the data was
>> inserted with DML (cache.put(key, BinaryObjects)) and there was no single
>> cache.put(key, new City()) that would register City class. Guess we need to
>> add an API that forces classes registration from the app side or something
>> more efficient.
>>
>> —
>> Denis
>
>

[dmagda]

Vladimir, thanks a lot for looking into this!

> On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <[hidden email]> wrote:
>
> Denis,
>
> Now more detailed answer:
>
> 1) It is expected that "City" class is not be found. You should set
> key/value type names to fully-qualified class name to make it work.
> Improvements: docs

To make the Class-based key-vakye access and deserialization workable did the following:
- follow your piece of advice providing full-qualified names in CREATE TABLE;
- comment out ‘simpleName’ binary names mapper [1].

However, it means that now the heterogeneous scenarios where .NET or C++ key-value access is needed are not supported. Do you have an understanding on how this can be done in the feature releases?

> 2) There is no need to implement hash code. Why did you do this?

That’s a big surprise that we calculate it automatically if a key is serialized into the binary form. Will be documented:
https://issues.apache.org/jira/browse/IGNITE-6717

> 3) We will not have case-insensitive policy, SQL databases doesn't work
> this way. In order to preserve case you should define column name in quotes.

Seems that the issue pin points to the affinity key case only:
- a field is defined as ‘CountryCode’ in DDL [2].
- in DML it can be used with any letters case - ‘countryCode’, ‘countrycode’, etc,
- BinaryObjectBuild allowed me to define the field as `countryCode` [3] w/o any issue.
- However, once I defined the field in CityKey class as is in DDL (`CountryCode`) the following exception was thrown:

Exception in thread "main" class org.apache.ignite.binary.BinaryObjectException: Binary type has different affinity key fields [typeName=demo.model.CityKey, affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=CountryCode]

and I forced to rename the field to `COUNTRYCODE` in CityKey class. Seems like a bug?

 
[1] https://github.com/dmagda/ignite_world_demo/blob/master/config/ignite-config.xml#L43
[2] https://github.com/dmagda/ignite_world_demo/blob/master/ignite_world.sql#L31
[3] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L75
[4] https://github.com/dmagda/ignite_world_demo/blob/master/src/main/java/demo/model/CityKey.java#L15

—
Denis

>
> On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Denis,
>>
>> SQL <-> key-Val transparency is complex thing, especially if you work with
>> real Java classes instead of binary objects.
>>
>> We will try to improve something in 2.4, but do not expect great usability
>> here. There is always be some pain in such scenarios.
>>
>> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
>>
>>>
>>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
>>>>
>>>> * failed to deserialize BinaryObject value to City type [7]. Just
>>> classical "class org.apache.ignite.binary.BinaryInvalidTypeException:
>>> City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
>>>
>>>
>>> Recalled that this should be caused by the fact that all the data was
>>> inserted with DML (cache.put(key, BinaryObjects)) and there was no single
>>> cache.put(key, new City()) that would register City class. Guess we need to
>>> add an API that forces classes registration from the app side or something
>>> more efficient.
>>>
>>> —
>>> Denis
>>
>>

[dsetrakyan]

It looks like the case sensitivity for the affinity key is a bug. Vladimir,
what do you think?

On Mon, Oct 23, 2017 at 11:19 AM, Denis Magda <[hidden email]> wrote:

> Vladimir, thanks a lot for looking into this!
>
> > On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <[hidden email]>
> wrote:
> >
> > Denis,
> >
> > Now more detailed answer:
> >
> > 1) It is expected that "City" class is not be found. You should set
> > key/value type names to fully-qualified class name to make it work.
> > Improvements: docs
>
> To make the Class-based key-vakye access and deserialization workable did
> the following:
> - follow your piece of advice providing full-qualified names in CREATE
> TABLE;
> - comment out ‘simpleName’ binary names mapper [1].
>
> However, it means that now the heterogeneous scenarios where .NET or C++
> key-value access is needed are not supported. Do you have an understanding
> on how this can be done in the feature releases?
>
> > 2) There is no need to implement hash code. Why did you do this?
>
> That’s a big surprise that we calculate it automatically if a key is
> serialized into the binary form. Will be documented:
> https://issues.apache.org/jira/browse/IGNITE-6717
>
> > 3) We will not have case-insensitive policy, SQL databases doesn't work
> > this way. In order to preserve case you should define column name in
> quotes.
>
> Seems that the issue pin points to the affinity key case only:
> - a field is defined as ‘CountryCode’ in DDL [2].
> - in DML it can be used with any letters case - ‘countryCode’,
> ‘countrycode’, etc,
> - BinaryObjectBuild allowed me to define the field as `countryCode` [3]
> w/o any issue.
> - However, once I defined the field in CityKey class as is in DDL
> (`CountryCode`) the following exception was thrown:
>
> Exception in thread "main" class org.apache.ignite.binary.BinaryObjectException:
> Binary type has different affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=CountryCode]
>
> and I forced to rename the field to `COUNTRYCODE` in CityKey class. Seems
> like a bug?
>
>
> [1] https://github.com/dmagda/ignite_world_demo/blob/master/
> config/ignite-config.xml#L43
> [2] https://github.com/dmagda/ignite_world_demo/blob/master/
> ignite_world.sql#L31
> [3] https://github.com/dmagda/ignite_world_demo/blob/master/
> src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L75
> [4] https://github.com/dmagda/ignite_world_demo/blob/master/
> src/main/java/demo/model/CityKey.java#L15
>
> —
> Denis
>
>
> >
> > On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> >> Denis,
> >>
> >> SQL <-> key-Val transparency is complex thing, especially if you work
> with
> >> real Java classes instead of binary objects.
> >>
> >> We will try to improve something in 2.4, but do not expect great
> usability
> >> here. There is always be some pain in such scenarios.
> >>
> >> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
> >>
> >>>
> >>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
> >>>>
> >>>> * failed to deserialize BinaryObject value to City type [7]. Just
> >>> classical "class org.apache.ignite.binary.BinaryInvalidTypeException:
> >>> City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
> >>>
> >>>
> >>> Recalled that this should be caused by the fact that all the data was
> >>> inserted with DML (cache.put(key, BinaryObjects)) and there was no
> single
> >>> cache.put(key, new City()) that would register City class. Guess we
> need to
> >>> add an API that forces classes registration from the app side or
> something
> >>> more efficient.
> >>>
> >>> —
> >>> Denis
> >>
> >>
>
>

[Vladimir Ozerov]

Denis,

Is it possible to create a test with reproducer? I am a bit lost.

On Tue, Oct 24, 2017 at 3:12 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> It looks like the case sensitivity for the affinity key is a bug. Vladimir,
> what do you think?
>
> On Mon, Oct 23, 2017 at 11:19 AM, Denis Magda <[hidden email]> wrote:
>
> > Vladimir, thanks a lot for looking into this!
> >
> > > On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <[hidden email]>
> > wrote:
> > >
> > > Denis,
> > >
> > > Now more detailed answer:
> > >
> > > 1) It is expected that "City" class is not be found. You should set
> > > key/value type names to fully-qualified class name to make it work.
> > > Improvements: docs
> >
> > To make the Class-based key-vakye access and deserialization workable did
> > the following:
> > - follow your piece of advice providing full-qualified names in CREATE
> > TABLE;
> > - comment out ‘simpleName’ binary names mapper [1].
> >
> > However, it means that now the heterogeneous scenarios where .NET or C++
> > key-value access is needed are not supported. Do you have an
> understanding
> > on how this can be done in the feature releases?
> >
> > > 2) There is no need to implement hash code. Why did you do this?
> >
> > That’s a big surprise that we calculate it automatically if a key is
> > serialized into the binary form. Will be documented:
> > https://issues.apache.org/jira/browse/IGNITE-6717
> >
> > > 3) We will not have case-insensitive policy, SQL databases doesn't work
> > > this way. In order to preserve case you should define column name in
> > quotes.
> >
> > Seems that the issue pin points to the affinity key case only:
> > - a field is defined as ‘CountryCode’ in DDL [2].
> > - in DML it can be used with any letters case - ‘countryCode’,
> > ‘countrycode’, etc,
> > - BinaryObjectBuild allowed me to define the field as `countryCode` [3]
> > w/o any issue.
> > - However, once I defined the field in CityKey class as is in DDL
> > (`CountryCode`) the following exception was thrown:
> >
> > Exception in thread "main" class org.apache.ignite.binary.
> BinaryObjectException:
> > Binary type has different affinity key fields
> [typeName=demo.model.CityKey,
> > affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=CountryCode]
> >
> > and I forced to rename the field to `COUNTRYCODE` in CityKey class. Seems
> > like a bug?
> >
> >
> > [1] https://github.com/dmagda/ignite_world_demo/blob/master/
> > config/ignite-config.xml#L43
> > [2] https://github.com/dmagda/ignite_world_demo/blob/master/
> > ignite_world.sql#L31
> > [3] https://github.com/dmagda/ignite_world_demo/blob/master/
> > src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L75
> > [4] https://github.com/dmagda/ignite_world_demo/blob/master/
> > src/main/java/demo/model/CityKey.java#L15
> >
> > —
> > Denis
> >
> >
> > >
> > > On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <[hidden email]
> >
> > > wrote:
> > >
> > >> Denis,
> > >>
> > >> SQL <-> key-Val transparency is complex thing, especially if you work
> > with
> > >> real Java classes instead of binary objects.
> > >>
> > >> We will try to improve something in 2.4, but do not expect great
> > usability
> > >> here. There is always be some pain in such scenarios.
> > >>
> > >> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
> > >>
> > >>>
> > >>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
> > >>>>
> > >>>> * failed to deserialize BinaryObject value to City type [7]. Just
> > >>> classical "class org.apache.ignite.binary.
> BinaryInvalidTypeException:
> > >>> City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
> > >>>
> > >>>
> > >>> Recalled that this should be caused by the fact that all the data was
> > >>> inserted with DML (cache.put(key, BinaryObjects)) and there was no
> > single
> > >>> cache.put(key, new City()) that would register City class. Guess we
> > need to
> > >>> add an API that forces classes registration from the app side or
> > something
> > >>> more efficient.
> > >>>
> > >>> —
> > >>> Denis
> > >>
> > >>
> >
> >
>

[dmagda]

Vladimir,

With pleasure, here is a ticker with the reproducer:
https://issues.apache.org/jira/browse/IGNITE-6785

—
Denis

> On Oct 24, 2017, at 5:57 AM, Vladimir Ozerov <[hidden email]> wrote:
>
> Denis,
>
> Is it possible to create a test with reproducer? I am a bit lost.
>
> On Tue, Oct 24, 2017 at 3:12 AM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
>> It looks like the case sensitivity for the affinity key is a bug. Vladimir,
>> what do you think?
>>
>> On Mon, Oct 23, 2017 at 11:19 AM, Denis Magda <[hidden email]> wrote:
>>
>>> Vladimir, thanks a lot for looking into this!
>>>
>>>> On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <[hidden email]>
>>> wrote:
>>>>
>>>> Denis,
>>>>
>>>> Now more detailed answer:
>>>>
>>>> 1) It is expected that "City" class is not be found. You should set
>>>> key/value type names to fully-qualified class name to make it work.
>>>> Improvements: docs
>>>
>>> To make the Class-based key-vakye access and deserialization workable did
>>> the following:
>>> - follow your piece of advice providing full-qualified names in CREATE
>>> TABLE;
>>> - comment out ‘simpleName’ binary names mapper [1].
>>>
>>> However, it means that now the heterogeneous scenarios where .NET or C++
>>> key-value access is needed are not supported. Do you have an
>> understanding
>>> on how this can be done in the feature releases?
>>>
>>>> 2) There is no need to implement hash code. Why did you do this?
>>>
>>> That’s a big surprise that we calculate it automatically if a key is
>>> serialized into the binary form. Will be documented:
>>> https://issues.apache.org/jira/browse/IGNITE-6717
>>>
>>>> 3) We will not have case-insensitive policy, SQL databases doesn't work
>>>> this way. In order to preserve case you should define column name in
>>> quotes.
>>>
>>> Seems that the issue pin points to the affinity key case only:
>>> - a field is defined as ‘CountryCode’ in DDL [2].
>>> - in DML it can be used with any letters case - ‘countryCode’,
>>> ‘countrycode’, etc,
>>> - BinaryObjectBuild allowed me to define the field as `countryCode` [3]
>>> w/o any issue.
>>> - However, once I defined the field in CityKey class as is in DDL
>>> (`CountryCode`) the following exception was thrown:
>>>
>>> Exception in thread "main" class org.apache.ignite.binary.
>> BinaryObjectException:
>>> Binary type has different affinity key fields
>> [typeName=demo.model.CityKey,
>>> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=CountryCode]
>>>
>>> and I forced to rename the field to `COUNTRYCODE` in CityKey class. Seems
>>> like a bug?
>>>
>>>
>>> [1] https://github.com/dmagda/ignite_world_demo/blob/master/
>>> config/ignite-config.xml#L43
>>> [2] https://github.com/dmagda/ignite_world_demo/blob/master/
>>> ignite_world.sql#L31
>>> [3] https://github.com/dmagda/ignite_world_demo/blob/master/
>>> src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L75
>>> [4] https://github.com/dmagda/ignite_world_demo/blob/master/
>>> src/main/java/demo/model/CityKey.java#L15
>>>
>>> —
>>> Denis
>>>
>>>
>>>>
>>>> On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <[hidden email]
>>>
>>>> wrote:
>>>>
>>>>> Denis,
>>>>>
>>>>> SQL <-> key-Val transparency is complex thing, especially if you work
>>> with
>>>>> real Java classes instead of binary objects.
>>>>>
>>>>> We will try to improve something in 2.4, but do not expect great
>>> usability
>>>>> here. There is always be some pain in such scenarios.
>>>>>
>>>>> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
>>>>>
>>>>>>
>>>>>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]> wrote:
>>>>>>>
>>>>>>> * failed to deserialize BinaryObject value to City type [7]. Just
>>>>>> classical "class org.apache.ignite.binary.
>> BinaryInvalidTypeException:
>>>>>> City" caused by "Caused by: java.lang.ClassNotFoundException: City”.
>>>>>>
>>>>>>
>>>>>> Recalled that this should be caused by the fact that all the data was
>>>>>> inserted with DML (cache.put(key, BinaryObjects)) and there was no
>>> single
>>>>>> cache.put(key, new City()) that would register City class. Guess we
>>> need to
>>>>>> add an API that forces classes registration from the app side or
>>> something
>>>>>> more efficient.
>>>>>>
>>>>>> —
>>>>>> Denis
>>>>>
>>>>>
>>>
>>>
>>

[Vladimir Ozerov]

Denis,

See my comment in the ticket. It is a problem with scripts, not with engine.

On Sat, Oct 28, 2017 at 12:25 AM, Denis Magda <[hidden email]> wrote:

> Vladimir,
>
> With pleasure, here is a ticker with the reproducer:
> https://issues.apache.org/jira/browse/IGNITE-6785
>
> —
> Denis
>
> > On Oct 24, 2017, at 5:57 AM, Vladimir Ozerov <[hidden email]>
> wrote:
> >
> > Denis,
> >
> > Is it possible to create a test with reproducer? I am a bit lost.
> >
> > On Tue, Oct 24, 2017 at 3:12 AM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> >> It looks like the case sensitivity for the affinity key is a bug.
> Vladimir,
> >> what do you think?
> >>
> >> On Mon, Oct 23, 2017 at 11:19 AM, Denis Magda <[hidden email]>
> wrote:
> >>
> >>> Vladimir, thanks a lot for looking into this!
> >>>
> >>>> On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <[hidden email]>
> >>> wrote:
> >>>>
> >>>> Denis,
> >>>>
> >>>> Now more detailed answer:
> >>>>
> >>>> 1) It is expected that "City" class is not be found. You should set
> >>>> key/value type names to fully-qualified class name to make it work.
> >>>> Improvements: docs
> >>>
> >>> To make the Class-based key-vakye access and deserialization workable
> did
> >>> the following:
> >>> - follow your piece of advice providing full-qualified names in CREATE
> >>> TABLE;
> >>> - comment out ‘simpleName’ binary names mapper [1].
> >>>
> >>> However, it means that now the heterogeneous scenarios where .NET or
> C++
> >>> key-value access is needed are not supported. Do you have an
> >> understanding
> >>> on how this can be done in the feature releases?
> >>>
> >>>> 2) There is no need to implement hash code. Why did you do this?
> >>>
> >>> That’s a big surprise that we calculate it automatically if a key is
> >>> serialized into the binary form. Will be documented:
> >>> https://issues.apache.org/jira/browse/IGNITE-6717
> >>>
> >>>> 3) We will not have case-insensitive policy, SQL databases doesn't
> work
> >>>> this way. In order to preserve case you should define column name in
> >>> quotes.
> >>>
> >>> Seems that the issue pin points to the affinity key case only:
> >>> - a field is defined as ‘CountryCode’ in DDL [2].
> >>> - in DML it can be used with any letters case - ‘countryCode’,
> >>> ‘countrycode’, etc,
> >>> - BinaryObjectBuild allowed me to define the field as `countryCode` [3]
> >>> w/o any issue.
> >>> - However, once I defined the field in CityKey class as is in DDL
> >>> (`CountryCode`) the following exception was thrown:
> >>>
> >>> Exception in thread "main" class org.apache.ignite.binary.
> >> BinaryObjectException:
> >>> Binary type has different affinity key fields
> >> [typeName=demo.model.CityKey,
> >>> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=CountryCode]
> >>>
> >>> and I forced to rename the field to `COUNTRYCODE` in CityKey class.
> Seems
> >>> like a bug?
> >>>
> >>>
> >>> [1] https://github.com/dmagda/ignite_world_demo/blob/master/
> >>> config/ignite-config.xml#L43
> >>> [2] https://github.com/dmagda/ignite_world_demo/blob/master/
> >>> ignite_world.sql#L31
> >>> [3] https://github.com/dmagda/ignite_world_demo/blob/master/
> >>> src/main/java/demo/keyvalue/KeyValueDataProcessing.java#L75
> >>> [4] https://github.com/dmagda/ignite_world_demo/blob/master/
> >>> src/main/java/demo/model/CityKey.java#L15
> >>>
> >>> —
> >>> Denis
> >>>
> >>>
> >>>>
> >>>> On Sat, Oct 21, 2017 at 2:34 PM, Vladimir Ozerov <
> [hidden email]
> >>>
> >>>> wrote:
> >>>>
> >>>>> Denis,
> >>>>>
> >>>>> SQL <-> key-Val transparency is complex thing, especially if you work
> >>> with
> >>>>> real Java classes instead of binary objects.
> >>>>>
> >>>>> We will try to improve something in 2.4, but do not expect great
> >>> usability
> >>>>> here. There is always be some pain in such scenarios.
> >>>>>
> >>>>> сб, 21 окт. 2017 г. в 9:23, Denis Magda <[hidden email]>:
> >>>>>
> >>>>>>
> >>>>>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <[hidden email]>
> wrote:
> >>>>>>>
> >>>>>>> * failed to deserialize BinaryObject value to City type [7]. Just
> >>>>>> classical "class org.apache.ignite.binary.
> >> BinaryInvalidTypeException:
> >>>>>> City" caused by "Caused by: java.lang.ClassNotFoundException:
> City”.
> >>>>>>
> >>>>>>
> >>>>>> Recalled that this should be caused by the fact that all the data
> was
> >>>>>> inserted with DML (cache.put(key, BinaryObjects)) and there was no
> >>> single
> >>>>>> cache.put(key, new City()) that would register City class. Guess we
> >>> need to
> >>>>>> add an API that forces classes registration from the app side or
> >>> something
> >>>>>> more efficient.
> >>>>>>
> >>>>>> —
> >>>>>> Denis
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>