[jira] [Comment Edited] (IGNITE-6785) Affinity field name forced to be upper-case

["Vladimir Ozerov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312896#comment-16312896 ] 

Vladimir Ozerov edited comment on IGNITE-6785 at 1/5/18 10:35 AM:
------------------------------------------------------------------

[~dmagda], cannot reproduce still. Please see attached PR where I extracted logic you mentioned in a separate test.
1) Your example doesn't work out of the box because you have upper-cased affinity key in SQL, but camel-cased in Java code. This is expected behavior. In my test I converted SQL part to camel case and everything works fine. Alternatively, you can change Java field name to {{COUNTRYCODE}}, and it will work as well.
2) As far as slow invoke - this is because you return {{entry}} from entry processor which is essentially incorrect API usage - this is our internal representation of an entry (see {{CacheInvokeEntry}} class). When you return it, we have to serialize huge graph of internal objects. Just change it to {{return null}} and everything will be fine.

I propose to close this ticket as won't fix as no issues are found.


was (Author: vozerov):
[~dmagda], cannot reproduce still. Please see attached PR where I extract logic you mentioned in a separate test.
1) Your example doesn't work out of the box because you have upper-cased affinity key in SQL, but camel-cased in Java code. This is expected behavior. In my test I converted SQL part to camel case and everything works fine. Alternatively, you can change Java field name to {{COUNTRYCODE}}, and it will work as well.
2) As far as slow invoke - this is because you return {{entry}} from entry processor which is essentially incorrect API usage - this is our internal representation of an entry (see {{CacheInvokeEntry}} class). When you return it, we have to serialize huge graph of internal objects. Just change it to {{return null}} and everything will be fine.

I propose to close this ticket as won't fix as no issues are found.

> Affinity field name forced to be upper-case
> -------------------------------------------
>
>                 Key: IGNITE-6785
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6785
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Denis Magda
>            Assignee: Denis Magda
>              Labels: important, usability
>             Fix For: 2.4
>
>         Attachments: sql_bug.zip
>
>
> If an SQL schema and cache is created with CREATE TABLE command and a user wants to use key-value APIs creating its own custom key class, then (at least) the key  class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> 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]
> 	at org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat} 
> If fact {{CityKey}} names the affinity field in the same way as in CREATE TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland, POPULATION=711200, NAME=Amsterdam]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)