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 >> >>
