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