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 <dsetrak...@apache.org> 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 <voze...@gridgain.com> > 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 <ag...@apache.org> 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 <dma...@apache.org> 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 <ag...@apache.org> > 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 > > > >> <ilya.kasnach...@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 <voze...@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¶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. > > > >> >> > > > >> > > > > > >
