Re: issues introducing non-reversible changes in the repository

[Marcel Reutegger]

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]

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"  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
>reka...@adobe.com
>

Re: issues introducing non-reversible changes in the repository

[Michael Marth]

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"  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
>reka...@adobe.com
>