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¶m2=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. |
Vladimir,
If we will use parentheses, do we really need "?" symbol? It looks redundant for me in case of parentheses. jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2) vs jdbc:ignite:thin://host:port/schema(param1=val1)(param2=val2) What do you think? On Tue, Apr 3, 2018 at 3:30 PM, Vladimir Ozerov <[hidden email]> wrote: > 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¶m2=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. > -- Alexey Kuznetsov |
In reply to this post by Vladimir Ozerov
Hi,
1. Mysql JDBC driver Conenctor/J [1] and postgres JDBC driver [2] use ampersand to delimit properties. 2. Mysql use regular URL encoding for properties values instead of legacy escaping (e.g braces etc.) 3. Microsoft JDBC (and ODBC) driver for SQL Server [3] use semicolon to delimit and square braces to escape. So, there is no true way to solve the issue. However, the inconvenience of using the console is the last thing I paid attention to. - using JDBC driver from console client is not common case; - when any command line shell is used the various escaping of the parameters is routine job. So, the root cause of the proposal is not clear for me. [1]. https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html [2]. https://jdbc.postgresql.org/documentation/80/connect.html [3]. https://msdn.microsoft.com/ru-ru/library/ms378428(v=sql.100).aspx On 03.04.2018 11:30, Vladimir Ozerov wrote: > 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¶m2=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. > -- Taras Ledkov Mail-To: [hidden email] |
Taras,
I spent today 30 minutes trying to connect to cluster with sqlline in Power Shell :( I predict 100500+ questions on user list about "Failed to connect in bash / cmd / powershell with sqlline" On Tue, Apr 3, 2018 at 3:55 PM, Taras Ledkov <[hidden email]> wrote: > Hi, > > 1. Mysql JDBC driver Conenctor/J [1] and postgres JDBC driver [2] use > ampersand to delimit properties. > 2. Mysql use regular URL encoding for properties values instead of legacy > escaping (e.g braces etc.) > 3. Microsoft JDBC (and ODBC) driver for SQL Server [3] use semicolon to > delimit and square braces to escape. > > So, there is no true way to solve the issue. > > However, the inconvenience of using the console is the last thing I paid > attention to. > - using JDBC driver from console client is not common case; > - when any command line shell is used the various escaping of the > parameters is routine job. > > So, the root cause of the proposal is not clear for me. > > [1]. https://dev.mysql.com/doc/connector-j/5.1/en/connector-j- > reference-configuration-properties.html > > [2]. https://jdbc.postgresql.org/documentation/80/connect.html > > [3]. https://msdn.microsoft.com/ru-ru/library/ms378428(v=sql.100).aspx > > On 03.04.2018 11:30, Vladimir Ozerov wrote: > >> 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¶m2=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. >> >> > -- > Taras Ledkov > Mail-To: [hidden email] > > -- Alexey Kuznetsov |
In reply to this post by Vladimir Ozerov
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 <[hidden email]>: > 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¶m2=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. > |
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 <[hidden email]> 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 <[hidden email]>: > >> 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¶m2=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. >> |
Vladimir, Taras,
Will "@" work for us as the delimiter? I would agree with Andrey to reuse this approach for the thin client. As for the breaking changes, if update the delimiter for the next driver version and make sure that version understands 2 delimiters for some time (& and the new one), then this would be ideal and not disrupting. -- Denis On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> wrote: > 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 > <[hidden email]> 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 <[hidden email]>: > > > >> 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¶m2=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. > >> > |
In reply to this post by Vladimir Ozerov
Vladimir, why can't we support both, the "&" and whatever other character
we choose? This way it will not be a breaking change. D. On Tue, Apr 3, 2018 at 1:30 AM, Vladimir Ozerov <[hidden email]> wrote: > 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¶m2=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. > |
In reply to this post by dmagda
Denis,
actually params (key-value pairs) are separated by colon in provided JIRA issue comment. On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > Vladimir, Taras, > > Will "@" work for us as the delimiter? I would agree with Andrey to reuse > this approach for the thin client. > > As for the breaking changes, if update the delimiter for the next driver > version and make sure that version understands 2 delimiters for some time > (& and the new one), then this would be ideal and not disrupting. > > -- > Denis > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> wrote: > >> 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 >> <[hidden email]> 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 <[hidden email]>: >> > >> >> 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¶m2=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. >> >> >> |
I think colon is not very good candidate as it clashes with other
properties (e.g. host-port delimiter). Semicolon looks good to me. I'll created a ticket [1] to address this. [1] https://issues.apache.org/jira/browse/IGNITE-8148 On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura <[hidden email]> wrote: > Denis, > > actually params (key-value pairs) are separated by colon in provided > JIRA issue comment. > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > > Vladimir, Taras, > > > > Will "@" work for us as the delimiter? I would agree with Andrey to reuse > > this approach for the thin client. > > > > As for the breaking changes, if update the delimiter for the next driver > > version and make sure that version understands 2 delimiters for some time > > (& and the new one), then this would be ideal and not disrupting. > > > > -- > > Denis > > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> wrote: > > > >> 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 > >> <[hidden email]> 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 <[hidden email]>: > >> > > >> >> 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¶m2=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. > >> >> > >> > |
Vladimir, my older email got kind of lost. Can you please clarify, will we
be able to support both, older and newer formats, to avoid a breaking compatibility change between releases? D. On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov <[hidden email]> wrote: > I think colon is not very good candidate as it clashes with other > properties (e.g. host-port delimiter). Semicolon looks good to me. I'll > created a ticket [1] to address this. > > [1] https://issues.apache.org/jira/browse/IGNITE-8148 > > On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura <[hidden email]> wrote: > > > Denis, > > > > actually params (key-value pairs) are separated by colon in provided > > JIRA issue comment. > > > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > > > Vladimir, Taras, > > > > > > Will "@" work for us as the delimiter? I would agree with Andrey to > reuse > > > this approach for the thin client. > > > > > > As for the breaking changes, if update the delimiter for the next > driver > > > version and make sure that version understands 2 delimiters for some > time > > > (& and the new one), then this would be ideal and not disrupting. > > > > > > -- > > > Denis > > > > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> wrote: > > > > > >> 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 > > >> <[hidden email]> 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 <[hidden email]>: > > >> > > > >> >> 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¶m2=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. > > >> >> > > >> > > > |
I mentioned this in the ticket. Hopefully, yes. There is a corner case when
both ampersands and semicolons are there - need to think better how to handle this. On Thu, Apr 5, 2018 at 3:56 PM, Dmitriy Setrakyan <[hidden email]> wrote: > Vladimir, my older email got kind of lost. Can you please clarify, will we > be able to support both, older and newer formats, to avoid a breaking > compatibility change between releases? > > D. > > On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov <[hidden email]> > wrote: > > > I think colon is not very good candidate as it clashes with other > > properties (e.g. host-port delimiter). Semicolon looks good to me. I'll > > created a ticket [1] to address this. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8148 > > > > On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura <[hidden email]> wrote: > > > > > Denis, > > > > > > actually params (key-value pairs) are separated by colon in provided > > > JIRA issue comment. > > > > > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > > > > Vladimir, Taras, > > > > > > > > Will "@" work for us as the delimiter? I would agree with Andrey to > > reuse > > > > this approach for the thin client. > > > > > > > > As for the breaking changes, if update the delimiter for the next > > driver > > > > version and make sure that version understands 2 delimiters for some > > time > > > > (& and the new one), then this would be ideal and not disrupting. > > > > > > > > -- > > > > Denis > > > > > > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> > wrote: > > > > > > > >> 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 > > > >> <[hidden email]> 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 <[hidden email] > >: > > > >> > > > > >> >> 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¶m2=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. > > > >> >> > > > >> > > > > > > |
In reply to this post by Vladimir Ozerov
Vladimir, Igor,
Shouldn't we do the same for ODBC? -- Denis On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov <[hidden email]> wrote: > I think colon is not very good candidate as it clashes with other > properties (e.g. host-port delimiter). Semicolon looks good to me. I'll > created a ticket [1] to address this. > > [1] https://issues.apache.org/jira/browse/IGNITE-8148 > > On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura <[hidden email]> wrote: > > > Denis, > > > > actually params (key-value pairs) are separated by colon in provided > > JIRA issue comment. > > > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > > > Vladimir, Taras, > > > > > > Will "@" work for us as the delimiter? I would agree with Andrey to > reuse > > > this approach for the thin client. > > > > > > As for the breaking changes, if update the delimiter for the next > driver > > > version and make sure that version understands 2 delimiters for some > time > > > (& and the new one), then this would be ideal and not disrupting. > > > > > > -- > > > Denis > > > > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> wrote: > > > > > >> 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 > > >> <[hidden email]> 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 <[hidden email]>: > > >> > > > >> >> 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¶m2=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. > > >> >> > > >> > > > |
ODBC uses semicolon and this semantics are defined by ODBC specification.
Best Regards, Igor On Thu, Apr 5, 2018 at 10:35 PM, Denis Magda <[hidden email]> wrote: > Vladimir, Igor, > > Shouldn't we do the same for ODBC? > > -- > Denis > > On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov <[hidden email]> > wrote: > > > I think colon is not very good candidate as it clashes with other > > properties (e.g. host-port delimiter). Semicolon looks good to me. I'll > > created a ticket [1] to address this. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8148 > > > > On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura <[hidden email]> wrote: > > > > > Denis, > > > > > > actually params (key-value pairs) are separated by colon in provided > > > JIRA issue comment. > > > > > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda <[hidden email]> wrote: > > > > Vladimir, Taras, > > > > > > > > Will "@" work for us as the delimiter? I would agree with Andrey to > > reuse > > > > this approach for the thin client. > > > > > > > > As for the breaking changes, if update the delimiter for the next > > driver > > > > version and make sure that version understands 2 delimiters for some > > time > > > > (& and the new one), then this would be ideal and not disrupting. > > > > > > > > -- > > > > Denis > > > > > > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura <[hidden email]> > wrote: > > > > > > > >> 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 > > > >> <[hidden email]> 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 <[hidden email] > >: > > > >> > > > > >> >> 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¶m2=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. > > > >> >> > > > >> > > > > > > |
Free forum by Nabble | Edit this page |