Re: Breaking change in JDBC connection string format

[Igor Sapego]

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  wrote:

> Vladimir, Igor,
>
> Shouldn't we do the same for ODBC?
>
> --
> Denis
>
> On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov 
> 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  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  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 
> 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=com.atlassian.jira.
> > > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > > >>
> > > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > > >>  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  >:
> > > >> >
> > > >> >> 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=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.
> > > >> >>
> > > >>
> > >
> >
>

Re: Breaking change in JDBC connection string format

[Denis Magda]

Vladimir, Igor,

Shouldn't we do the same for ODBC?

--
Denis

On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov 
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  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  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  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=com.atlassian.jira.
> > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > >>
> > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > >>  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 :
> > >> >
> > >> >> 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=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.
> > >> >>
> > >>
> >
>

Re: Breaking change in JDBC connection string format

[Vladimir Ozerov]

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 
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 
> 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  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  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 
> 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=com.atlassian.jira.
> > > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > > >>
> > > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > > >>  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  >:
> > > >> >
> > > >> >> 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=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.
> > > >> >>
> > > >>
> > >
> >
>

Re: Breaking change in JDBC connection string format

[Dmitriy Setrakyan]

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 
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  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  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  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=com.atlassian.jira.
> > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > >>
> > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > >>  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 :
> > >> >
> > >> >> 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=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.
> > >> >>
> > >>
> >
>

Re: Breaking change in JDBC connection string format

[Vladimir Ozerov]

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  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  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  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=com.atlassian.jira.
> >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> >>
> >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> >>  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 :
> >> >
> >> >> 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=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.
> >> >>
> >>
>

Re: Breaking change in JDBC connection string format

[Andrey Gura]

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  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  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=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
>>
>> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
>>  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 :
>> >
>> >> 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=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.
>> >>
>>

Re: Breaking change in JDBC connection string format

[Dmitriy Setrakyan]

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 
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=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.
>

Re: Breaking change in JDBC connection string format

[Denis Magda]

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  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=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
>
> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
>  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 :
> >
> >> 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=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.
> >>
>

Re: Breaking change in JDBC connection string format

[Andrey Gura]

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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14706511

On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
 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 :
>
>> 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=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.
>>

Re: Breaking change in JDBC connection string format

[Ilya Kasnacheev]

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 :

> 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=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.
>

Re: Breaking change in JDBC connection string format

[Alexey Kuznetsov]

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  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=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: tled...@gridgain.com
>
>


-- 
Alexey Kuznetsov

Re: Breaking change in JDBC connection string format

[Taras Ledkov]

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=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: tled...@gridgain.com

Re: Breaking change in JDBC connection string format

[Alexey Kuznetsov]

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

Breaking change in JDBC connection string format

[Vladimir Ozerov]

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=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.