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 Tue, 03 Oct 2017 08:15:33 GMT
Hi Guys,


I want to share the first experience of using the utility for compatibility
testing.


As part of the task to improve storage folders in PDS, I wrote 2 tests
(IGNITE 6285, FoldersReuseCompatibilityTest). These tests run versions 2.1
and 2.2, create storage, and then run the grid on new folders. It's very
easy to create such a test based on DummyPersistenceTest.


Since the test runs a grid on a separate JVM, it is always important to
call stopAllGrids ()


I want to thank the Vyacheslav D. for this improvement.


Tests are performed in the Compatiblity suite. The suite is run in the
chain RunAll, and daily for master.


Sincerely,

Dmitriy Pavlov

чт, 21 сент. 2017 г. в 0:39, Dmitry Pavlov <dpavlov.spb@gmail.com>:

> 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