Thanks, Alexey! I'll update the docs.
-P
On Fri, Mar 2, 2018 at 1:42 AM, Alexey Kuznetsov
wrote:
> I merged IGNITE-7803 into master.
> Created ticket for documentation: https://issues.
> apache.org/jira/browse/IGNITE-7867
>
> Prachi, could you update documentation for REST?
>
> On Thu, Mar 1, 2
I merged IGNITE-7803 into master.
Created ticket for documentation:
https://issues.apache.org/jira/browse/IGNITE-7867
Prachi, could you update documentation for REST?
On Thu, Mar 1, 2018 at 2:41 PM, Alexey Kuznetsov
wrote:
> Vladimir,
>
> I finished with this feature: https://issues.
> apache.o
Vladimir,
I finished with this feature:
https://issues.apache.org/jira/browse/IGNITE-7803
Could you please review my changes in branch ignite-7803?
DIFF:
https://github.com/apache/ignite/commit/da03195ef5c39deabfc4961b2a0336fdbc98aa31
--
Alexey Kuznetsov
> private int orgId;
> public int getOrganizationId() {...}
What an insane naming convention, who would do that? :)
Anyway, JSON field names should match binary metadata.
We have SQL via REST, so users would expect to use the same field names in
binary objects and SQL queries.
On Tue, Feb 27,
Hi guys,
1. Alex, the point that Pavel tried to convey is that a user who will
get/put data using REST doesn't care if the data will be deserialized on
the server side. It just needs to work. So, the same user shouldn't know
about the keepBinary parameter, just turn it on for REST protocol by
defa
Vova, Pavel, Sergey,
Thanks for you comments.
1) There one corner case with POJO objects in cache.
Binary marshaler convert by fields, not by getters. So if you have
class Person {
private int orgId;
...
public int getOrganizationId() {...}
}
POJO will be transformed to {"organizationId":
Vova, Alexey
3) The exception is not enough for that case. We should return a proper
error message in the json reply.
On Mon, Feb 26, 2018 at 2:20 PM, Vladimir Ozerov
wrote:
> My 50 cents:
> 1) Agree with Pavel, not need to deserialize at all
> 2) May be you see everything in the upper case bec
My 50 cents:
1) Agree with Pavel, not need to deserialize at all
2) May be you see everything in the upper case because this is how CREATE
TABLE works - every object name (table name, column name, etc.) are
converted to upper case by default. This is expected behavior of every SQL
engine. If you wa
Hi Alexey,
1) IMO for this task you should ALWAYS work in binary mode.
What is the use case for deserializing with a real class and then
serializing to JSON?
Looks like a waste of resources to me.
2) This should not be the case, please re-check your code.
Binary meta preserves original case (stor