Re: Binary compatibility of persistent storage

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

Re: Binary compatibility of persistent storage

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

Re: Binary compatibility of persistent storage

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

Re: Binary compatibility of persistent storage

Igniters, The compatibility testing framework [1] will be completed soon. We will be able to cover all the cases suggested by Vladimir, for example: >> 2) No compatibility, but provide migration instruments It will be possible to test migration tools and scenarios provided to the end users.

Re: Binary compatibility of persistent storage

In my view, there are two different scenarios. First - user just upgrades the version (to get some bug fix, for example), but does not intend to change anything in their project and/or use any new features. In this case it should work transparently and cluster must be able to work with older

Re: Binary compatibility of persistent storage

>Any major change in data/index page format. E.g. this could happen once transactional SQL is ready. I would suggest we automatically disable this feature for databases created with older versions. --Yakov

Re: Binary compatibility of persistent storage

I vote for the 4th variant, because it is the most common approach to the versioning. For example, SemVer says that you can make incompatible API changes only in major versions. 19.09.2017, 14:52, "Vladimir Ozerov" : > Yakov, > > Any major change in data/index page

Re: Binary compatibility of persistent storage

Yakov, Any major change in data/index page format. E.g. this could happen once transactional SQL is ready. On Tue, Sep 19, 2017 at 2:51 PM, Yakov Zhdanov wrote: > Vladimir, > > Can you please describe the situation when 2 is possible, but 4 is not? > > --Yakov >

Re: Binary compatibility of persistent storage

I have same idea about testing of WAL compatibilty between releases. It will be actual since 2.3 release (as 2.2 was emergency release without impact changes). I look forward to IGNITE-5732 completion and merge. And then I able to start writting first test. I think it is quite unexpected for

Re: Binary compatibility of persistent storage

I vote for: “4) Maintain compatibility between all versions within major release”. I think this is a trade-off between the complexity of implementing new features and UX. We will be able to get rid of all legacy tools every major release. I’m working on a testing framework, which helps us

Re: Binary compatibility of persistent storage

Vladimir, Can you please describe the situation when 2 is possible, but 4 is not? --Yakov

Re: Binary compatibility of persistent storage

Hello, Vladimir. I prefer 2 option. > 2) No compatibility, but provide migration instruments I think we have to provide some tool for converting WAL files from any older format to current. 19.09.2017 14:16, Vladimir Ozerov пишет: igniters, Ignite doesn't have compatibility for binary

Re: Binary compatibility of persistent storage

Vote for case #4. As far as I know, Vyacheslav Daradur already works on framework allows to check compatibility between different version of Ignite. Vyacheslav, Could you provide us more details? On Tue, Sep 19, 2017 at 2:16 PM, Vladimir Ozerov wrote: > igniters, > >

Binary compatibility of persistent storage

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