ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Breaking change in JDBC connection string format
Date Thu, 05 Apr 2018 13:05:51 GMT
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 <dsetrakyan@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 <vozerov@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 <agura@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 <dmagda@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 <agura@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.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message