ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Pavlov <dpavlov....@gmail.com>
Subject Re: Binary compatibility of persistent storage
Date Wed, 20 Sep 2017 21:39:49 GMT
Denis, the argument sounds convincing to me. When you use 3rd party DB, you
rarely have to care how to migrate DB data.

Igniters, I suggest keeping compatibility as long as we can, even with the
transition to a new major release. If incompatibility will become
unavoidable we will consider migration procedures.

чт, 21 сент. 2017 г. в 0:21, Denis Magda <dmagda@apache.org>:

> Either 3 or 4 looks as an appropriate approach for me. Ignite is no longer
> just an in-memory storage and we can not afford to force our users to
> migrate the data or configuration just because of the new cool feature in a
> new version. We should provide the same level of compatibility as RDBMS
> vendors do.
>
> —
> Denis
>
> > On Sep 19, 2017, at 4:16 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
> >
> > igniters,
> >
> > Ignite doesn't have compatibility for binary protocols between different
> > versions, as this would make development harder and slower. On the other
> > hand we maintain API compatibility what helps us move users to new
> versions
> > faster.
> >
> > As native persistence is implemented, new challenge appeared - whether to
> > maintain binary compatibility of stored data. Many approaches exist:
> >
> > 1) No compatibility at all - easy for us, nightmare for users (IMO)
> > 2) No compatibility, but provide migration instruments
> > 3) Maintain compatibility between N latest minor versions
> > 4) Maintain compatibility between all versions within major release
> >
> > The more guarantees we offer, the harder them to maintain, the better UX.
> >
> > Let's think on what compatibility mode we can offer to our users if any.
> > Any ideas?
> >
> > Vladimir.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message