issues introducing non-reversible changes in the repository

[Tomek Rekawek <re...@adobe.com>]

Hi,

Some of the Oak users are interested in rolling back the Oak upgrade within a branch (like 1.4.10 -> 1.4.1). As far as I understand, it should work, unless some of the commits in (1.4.10, 1.4.10] introduces a repository format change that is not compatible with the previous version (eg. modifies the format of a property in the DocumentMK).

Right now there’s no way to check this other than reviewing all the issues in the given version range related to the given components.

Maybe it’d be useful to mark such issues with a label (like “breaks_compatibility”, “non_reversible", “updates_schema”, etc.)?

WDYT? Which label should we choose and how we can make sure that it’s really used in appropriate cases?

Regards,
Tomek

-- 
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com

Re: issues introducing non-reversible changes in the repository

[Michael Marth <mm...@adobe.com>]

Hi Tomek,

This was discussed a while (roughly a year) back on the list and rejected at that time due to the complexity that comes with supporting downgrades (sorry, don’t have the link to that thread handy).
Maybe a middle ground would be using the “non_reversible” tag so that users can make an informed decision about upgrading, but not supporting downgrades?

my2c

Cheers
Michael



On 11/01/17 11:26, "Tomek Rekawek" <re...@adobe.com> wrote:

>Hi,
>
>Some of the Oak users are interested in rolling back the Oak upgrade within a branch (like 1.4.10 -> 1.4.1). As far as I understand, it should work, unless some of the commits in (1.4.10, 1.4.10] introduces a repository format change that is not compatible with the previous version (eg. modifies the format of a property in the DocumentMK).
>
>Right now there’s no way to check this other than reviewing all the issues in the given version range related to the given components.
>
>Maybe it’d be useful to mark such issues with a label (like “breaks_compatibility”, “non_reversible", “updates_schema”, etc.)?
>
>WDYT? Which label should we choose and how we can make sure that it’s really used in appropriate cases?
>
>Regards,
>Tomek
>
>-- 
>Tomek Rękawek | Adobe Research | www.adobe.com
>rekawek@adobe.com
>

Re: issues introducing non-reversible changes in the repository

[Marcel Reutegger <mr...@adobe.com>]

Hi,

On 11/01/17 12:19, Thomas Mueller wrote:
> If there are changes, then trying to start with an old version
> (1.2.x) should fail. It might be possible to open the repository in
> read-only mode; for that, then a "read" and a "write" version could
> be used, as this is done in SQLite for example
> (https://www.sqlite.org/fileformat.html - File Format Version
> Numbers). So that it's possible to open a repository in read-only
> mode, if the read-version is the same.

This is also my preferred way to handle this situation.

There is an existing issue about where this is discussed as well:
https://issues.apache.org/jira/browse/OAK-4529

> Not sure if it makes sense to support the read-only mode in Oak.

The DocumentNodeStore and I think also the SegmentNodeStore already have 
a read-only mode and it wouldn't be too difficult to allow at least 
reads when possible.

Regards
  Marcel

Re: issues introducing non-reversible changes in the repository

[Thomas Mueller <mu...@adobe.com>]

Hi,

I think within a major version of Oak (1.4.x, 1.6.x), there should be no
backward-incompatible data format changes.

If there are changes, then trying to start with an old version (1.2.x)
should fail. It might be possible to open the repository in read-only
mode; for that, then a "read" and a "write" version could be used, as this
is done in SQLite for example (https://www.sqlite.org/fileformat.html -
File Format Version Numbers). So that it's possible to open a repository
in read-only mode, if the read-version is the same. Not sure if it makes
sense to support the read-only mode in Oak.

Regards,
Thomas



On 11/01/17 11:26, "Tomek Rekawek" <re...@adobe.com> wrote:

>Hi,
>
>Some of the Oak users are interested in rolling back the Oak upgrade
>within a branch (like 1.4.10 -> 1.4.1). As far as I understand, it should
>work, unless some of the commits in (1.4.10, 1.4.10] introduces a
>repository format change that is not compatible with the previous version
>(eg. modifies the format of a property in the DocumentMK).
>
>Right now there's no way to check this other than reviewing all the
>issues in the given version range related to the given components.
>
>Maybe it'd be useful to mark such issues with a label (like
>"breaks_compatibility", "non_reversible", "updates_schema", etc.)?
>
>WDYT? Which label should we choose and how we can make sure that it's
>really used in appropriate cases?
>
>Regards,
>Tomek
>
>-- 
>Tomek Rękawek | Adobe Research | www.adobe.com
>rekawek@adobe.com
>