[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-08-24 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-1250:
-

Implemented.

Proper connection implementation will be created accordingly to provided JDBC 
connection URL.

If URL has {{jdbc:ignite://host:port/cache?nodeId=UUID}} format then Ignite 
Java client based connection will be created.
If URL has {{jdbc:ignite:cfg://[@]}} format then Ignite 
client node based connection will be created.

Ignite client based connection implementation is placed in 
{{org.apache.ignite.internal.jdbc2}} packacge. It is internal package, so it 
can be renamed with out affecting client code.

PR created https://github.com/apache/ignite/pull/29

Please review.

> 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: Andrey Gura
> 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)


[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-08-25 Thread Valentin Kulichenko (JIRA)

[ 
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 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)


[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-08-28 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-1250:
-

* Driver will just ignore cfg path. Of course, user can add {{ignite.jdbc.cfg}} 
property and pass properties to {{connect}} method, but it property isn't 
documented and builds from URL. We can change {{connect}} method in order to 
check URL prefix, not {{PROP_CFG}} property before connection instance creation.
* {{JdbcConnectionValidationTask}} checks that at least one node in cluster has 
cache with given name (or default). I think it should be optimized for case 
with {{nodeId}} parameter provided. 
* Good point. I'll optimize it. May be create new ticket for this task, because 
it related with both driver versions?
* Ok. May be we should create new ticket for this task, because it related with 
both driver versions?
* Ok. May be we should create new ticket for this task, because it related with 
both driver versions?
* Ok. May be we should create new ticket for this task, because it related with 
both driver versions?
* Yes, we can close cursor with result set. Good point!
* Ok. May be we should create new ticket for this task, because it related with 
both driver versions?
* You are right. Unsuccessful refactoring :) I'll fix it.
* Yes, {{JdbcUtils.sqlType}} call is redundant in {{JdbcResultSet.next}}. Will 
fix.
* Yes, it can cause issues. Will fix.
* Ok. May be we should create new ticket for this task, because it related with 
both driver versions?
* It should be discussed. Also this problem is actual for both driver versions.


> 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: Andrey Gura
> 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)


[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-08-31 Thread Valentin Kulichenko (JIRA)

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

Valentin Kulichenko commented on IGNITE-1250:
-

* If configuration path is ignored, warning should be printed out in log.
* I think we should simplify and get rid of all tasks, at least in case of 
client execution (this is how the driver will be used in 99% cases). Move the 
code to separate methods and call it either from task (if needed) or directly 
from driver classes.
* We don't need to fix old version - it's deprecated (BTW, this should be 
mentioned in docs). It just needs to work like it worked earlier for 
compatibility. All fixes go for the new version. I would fix everything in this 
ticket - there is nothing really complicated.
* I will think about user objects. Let's fix the rest first.

> 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)


[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-09-07 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-1250:
-

Valentin,

new PR created https://github.com/apache/ignite/pull/73 (where ignite-1.4 
branch is base).

All issues was fixed. Please review.

> 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: Andrey Gura
> 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)


[jira] [Commented] (IGNITE-1250) Migrate JDBC driver from Java client to Ignite node in client mode

2015-09-09 Thread Andrey Gura (JIRA)

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

Andrey Gura commented on IGNITE-1250:
-

New PR created because ignite-1.4 branch is removed - 
https://github.com/apache/ignite/pull/81

> 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)