ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@apache.org>
Subject Re: Breaking change in JDBC connection string format
Date Tue, 03 Apr 2018 09:39:25 GMT
Hi,

We've been solve this problem during JDBC2 driver implementation. And
I don't know any complains about connection string format. Why we can
just use the same approach? [1]

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

On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
<ilya.kasnacheev@gmail.com> wrote:
> Hello!
>
> I think semicolon is the way to go, since round brackets are often
> interpreted by shells and will need escaping on their own. Let's get rid of
> & and ?.
>
> jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
>
> --
> Ilya Kasnacheev
>
> 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
>> Igniters,
>>
>> Thanks to Alex Kuznetsov, we revealed serious usability issue in our thin
>> JDBC driver - we user ampersand character to delimit properties:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
>>
>> This leads to multiple problems:
>> 1) This format is unusable from many console environments and require
>> special escaping (PowerShell, bash)
>> 2) Also this causing issues when writing connection string is passed to
>> some 3rd-party applications as sometimes they cannot escape it as well.
>>
>> I performed investigation on how other vendors do that. Bottom line -
>> nobody use ampersand. Instead semicolon or parentheses are used:
>>
>> jdbc:ignite:thin://host:port/schema?param1=val1&param2=val2
>> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
>>
>> I propose to do a breaking change in AI 2.5 and change the format to
>> *parentheses*. This would be a disruptive experience for existing users,
>> but in the long term benefits will outweight. Also remember that we do not
>> offered officially any backward compatibility for our JDBC driver.
>>
>> Alternatively we may allow users to use previous format with help of system
>> property or environment variable.
>>
>> Thoughts?
>>
>> Vladimir.
>>

Mime
View raw message