[jira] [Comment Edited] (IGNITE-7253) JDBC thin driver: introduce streaming mode

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

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

Vladimir Ozerov edited comment on IGNITE-7253 at 3/2/18 12:56 PM:
------------------------------------------------------------------

[~al.psc], my comments:
1) ConnectionPropertiesImpl.LongProperty - appears to be a dead code
2) org.apache.ignite.internal.jdbc.thin.JdbcThinConnection#setStream - dead code
3) JdbcThinStatement.isEligibleForNativeParsing - executed twice every time. Why?
4) GridQueryProcessor.cliCtxs - why do we need to track these objects? AFAIK data streamers are already closed by DataStreamerProcessor during node stop
5) JdbcThinConnection - why do we need {{synchronized}} on some methods? Connection is single-threaded object already.
6) JdbcThinConnection.drainBatchToStreamIfNeeded - looks like it would return incorrect update count when executed on half-formed batch; IMO it is better to throw an exception if there is something prebatched.
7) Looks like it is allowed to execute DDL statements in streaming mode at the moment ({{streamBatchedUpdateQuery}} -> {{tryQueryDistributedSqlFieldsNative}}), which is wrong. Instead of adding a command to batch, I would set a special flag in it to close the streaming. This way you would not have to parse {{STREAMING OFF}} on the server.


was (Author: vozerov):
[~al.psc], my comments:
1) ConnectionPropertiesImpl.LongProperty - appears to be a dead code
2) org.apache.ignite.internal.jdbc.thin.JdbcThinConnection#setStream - dead code
3) JdbcThinStatement.isEligibleForNativeParsing - executed twice every time. Why?
4) GridQueryProcessor.cliCtxs - why do we need to track these objects? AFAIK data streamers are already closed by DataStreamerProcessor during node stop
5) JdbcThinConnection - why do we need {{synchronized}} on some methods? Connection is single-threaded object already.
6) JdbcThinConnection.drainBatchToStreamIfNeeded - looks like it would return incorrect update count when executed on half-formed batch; IMO it is better to throw an exception if there is something prebatched.

> JDBC thin driver: introduce streaming mode
> ------------------------------------------
>
>                 Key: IGNITE-7253
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7253
>             Project: Ignite
>          Issue Type: Task
>          Components: jdbc, sql
>            Reporter: Vladimir Ozerov
>            Assignee: Alexander Paschenko
>            Priority: Major
>             Fix For: 2.5
>
>         Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for JDBC driver. In this mode only INSERTs without SELECT should be possible. All other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an exception
> 4) It should be possible to stream into several tables simultaneously (i.e. several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)