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 <voze...@gridgain.com> 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 <dsetrak...@apache.org> > 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 <dma...@apache.org> wrote: >> >>> Vladimir, thanks a lot for looking into this! >>> >>>> On Oct 23, 2017, at 12:35 AM, Vladimir Ozerov <voze...@gridgain.com> >>> 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 <voze...@gridgain.com >>> >>>> 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 <dma...@apache.org>: >>>>> >>>>>> >>>>>>> On Oct 20, 2017, at 3:56 PM, Denis Magda <dma...@apache.org> 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 >>>>> >>>>> >>> >>> >>
