[
https://issues.apache.org/jira/browse/IGNITE-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712436#comment-14712436
]
Valentin Kulichenko commented on IGNITE-1250:
---------------------------------------------
Andrey,
Here are my comments/questions:
* How will the driver be configured if both old URL with host:port and cfg path
in Properties are provided? Is it valid? Should we throw an exception in this
case?
* What is the purpose of {{JdbcConnectionValidationTask}}? I assume it makes
sense to use it only for local caches in case of {{nodeId}} is set. But it
checks all nodes which looks suspicious.
* {{JdbcResultSet.getTypedValue(String colLb, Class<T> cls)}} uses {{indexOf}}
to find the field index. I don't like that we iterate each time we call
{{getXXX()}} method. Instead we can lazily create a corresponding hash map and
use it afterwards. Note that we can reuse it for all executions within one
prepared statement and in this case it can give improvement. What do you think?
* Removal delay in {{JdbcQueryTask}} should be customizable via system property.
* User should be able to provide all parameters of {{SqlFieldsQuery}}. Now
{{collocated}} and {{local}} are missing.
* When {{nodeId}} is provided, we should verify that it's a server node
(probably should be done in {{isValid()}} method).
* I don't like that we schedule cursor removal in case of client execution (no
{{nodeId}} is provided). Why don't we just remove the cursor on result set
closure?
* Need to make sure that when statement is closed, all result sets created by
this statement are closed too. Similarly, connection should close its
statements.
* The replacement of cursor on line 139 of {{JdbcQueryTask}} causes serious
issue: you try to take new iterator from {{QueryCursor}} which is wrong.
Moreover, it's not supported by {{QueryCursor}} and, as far as I understand,
you will get exception if there are more than two pages in result set. Please
add tests and fix properly.
* {{JdbcResultSet.next()}} iterates through fields to check types. But the same
is done in {{JdbcQueryTask}}, so it looks obsolete. Please check.
* {{UUID}} used to identify the cursor comes from the statement. So for
prepared statement it will be the same for different executions. Can it cause
issues?
* {{JdbcUtils.typeName()}} and {{JdbcUtils.type()}} methods miss
{{java.sql.Date}} type.
* I don't think we should convert user objects to strings. If user queries
objects (e.g., _VAL field), he will need to have classes anyway. So no reason
to convert them.
> Migrate JDBC driver from Java client to Ignite node in client mode
> ------------------------------------------------------------------
>
> Key: IGNITE-1250
> URL: https://issues.apache.org/jira/browse/IGNITE-1250
> Project: Ignite
> Issue Type: Improvement
> Reporter: Andrey Gura
> Assignee: Valentin Kulichenko
> Fix For: ignite-1.4
>
>
> JDBC driver is still based on legacy Java client which is deprecated, not
> supported and much slower than native query API.
> Needs to replace thin client with an embedded client node.
> See also:
> http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-driver-td2177.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
