[jira] [Comment Edited] (IGNITE-6244) .NET: Thin client: ScanQuery

["Pavel Tupitsyn (JIRA)" <ji...@apache.org>]

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

Pavel Tupitsyn edited comment on IGNITE-6244 at 9/11/17 1:52 PM:
-----------------------------------------------------------------

[~vozerov],
1) This is not even done in thick client yet: https://issues.apache.org/jira/browse/IGNITE-4070. Let's do separately.
2) ODBC/JDBC way is just more verbose, slower, and duplicates logic (switch on op code, then switch on response type).
3) Server side is not concerned with that flag. Server always works in binary mode (because it does not even know how to deserialize client objects). All client-related stuff can reside in the filter binary object. It is also easier to add other flags in future.
4) This makes sense, but looks like a very rare use case, and is difficult to implement. Let's add this later. Current protocol includes a filter type code, so we can add Java at any moment without protocol modification.
5) Weird question. It is clearly not just a map: there is id handling logic, cleanup logic, exceptions. This defines a clear use case. Why would we merge that into connection context, violate SRP, make code more difficult to understand? Also there is a {{HandleRegistry}} in .NET, so it may be already familiar to some developers.


was (Author: ptupitsyn):
1) This is not even done in thick client yet: https://issues.apache.org/jira/browse/IGNITE-4070. Let's do separately.
2) ODBC/JDBC way is just more verbose, slower, and duplicates logic (switch on op code, then switch on response type).
3) Server side is not concerned with that flag. Server always works in binary mode (because it does not even know how to deserialize client objects). All client-related stuff can reside in the filter binary object. It is also easier to add other flags in future.
4) This makes sense, but looks like a very rare use case, and is difficult to implement. Let's add this later. Current protocol includes a filter type code, so we can add Java at any moment without protocol modification.
5) Weird question. It is clearly not just a map: there is id handling logic, cleanup logic, exceptions. This defines a clear use case. Why would we merge that into connection context, violate SRP, make code more difficult to understand? Also there is a {{HandleRegistry}} in .NET, so it may be already familiar to some developers.

> .NET: Thin client: ScanQuery
> ----------------------------
>
>                 Key: IGNITE-6244
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6244
>             Project: Ignite
>          Issue Type: Improvement
>          Components: platforms
>            Reporter: Pavel Tupitsyn
>            Assignee: Pavel Tupitsyn
>              Labels: .NET
>             Fix For: 2.3
>
>
> Implement ScanQuery in thin client.
> Challenges:
> * Query cursor. This will require some kind of HandleRegistry on Java side, so we can pass an ID back to client (see {{OdbcRequestHandler.qryCursors}} as an example).
> * Predicate. Thin client is not .NET-specific. We need a way to support predicates in (at least) Java and .NET, there should be some platform id.



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