Backwards compatibility

[Dirkjan Ochtman <di...@ochtman.nl>]

I was just trying to upgrade the first of my servers to 1.2, and it
wasn't that pretty. As I understand it, compatibility with pre-0.10.0
databases has been dropped. However, this isn't mentioned in the
release notes, nor in the Breaking changes. Thus, I had to downgrade
to 1.1.1, compact a database and install 1.2.0 again. This is just a
PITA, and it seems fairly trivial that something like this should be
in the release notes and in the breaking changes.

Apart from that, it's also just a pain to find out if I have any
databases in an old version. The only simple way that I can see is
looking at the /db page (either in a browser or scripted), for each
database. It would be helpful if there was perhaps something like a
Futon page listing my databases along with their on-disk version
numbers and perhaps other relevant sysadmin information (like on-disk
size and the new percentage that's used to trigger auto-compaction).

As it is, I wasn't aware of the relevance of the on-disk format
version, so some databases that just don't need compaction (either
because they don't change that often, or because there's not that many
documents in there) didn't get compacted. I think I'm perhaps slightly
more attuned to the internals of CouchDB (at least I read the
developer mailing list) than the average user, so this might be even
worse for other users.

Also, perhaps the auto-compaction can be upgraded to (optionally) also
compact if the on-disk version if older than current-1, so people
don't have to pay as much attention to this. Presumably there's
already some scheduling going on to prevent auto-compaction from
hitting every database at the same time.

Cheers,

Dirkjan

P.S. I'm slightly annoyed, and it probably shows; I hope that doesn't
diminish the value of this feedback.

Re: Backwards compatibility

[Jason Smith <jh...@iriscouch.com>]

CouchDB without _users is much like a Unix server without NIS or LDAP.
Normal user accounts are inaccessible but administrator (root) users
can log in since their authentication is independent of the more fancy
system.

On Mon, Apr 9, 2012 at 1:16 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Mon, Apr 9, 2012 at 15:12, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> I was just trying to upgrade the first of my servers to 1.2, and it
>> wasn't that pretty. As I understand it, compatibility with pre-0.10.0
>> databases has been dropped. However, this isn't mentioned in the
>> release notes, nor in the Breaking changes. Thus, I had to downgrade
>> to 1.1.1, compact a database and install 1.2.0 again. This is just a
>> PITA, and it seems fairly trivial that something like this should be
>> in the release notes and in the breaking changes.
>
> Forgot to mention something I'm not sure is an issue, but should be
> checked: how resistant is CouchDB against inaccessible _users or
> _replicator? It seems like even _users might at some point be in an
> unsupported on-disk version. I run all of my couches in Admin Party
> mode so I never even look at the _users database, but it probably
> wouldn't work all that well.
>
> Cheers,
>
> Dirkjan



-- 
Iris Couch

Re: Backwards compatibility

[Robert Newson <rn...@apache.org>]

I've updated the wiki page to reflect this. Sorry for not including
this in Breaking Changes at release time.

B.

On 9 April 2012 09:41, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Apr 9, 2012 at 9:16 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> On Mon, Apr 9, 2012 at 15:12, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>>> I was just trying to upgrade the first of my servers to 1.2, and it
>>> wasn't that pretty. As I understand it, compatibility with pre-0.10.0
>>> databases has been dropped. However, this isn't mentioned in the
>>> release notes, nor in the Breaking changes. Thus, I had to downgrade
>>> to 1.1.1, compact a database and install 1.2.0 again. This is just a
>>> PITA, and it seems fairly trivial that something like this should be
>>> in the release notes and in the breaking changes.
>>
>> Forgot to mention something I'm not sure is an issue, but should be
>> checked: how resistant is CouchDB against inaccessible _users or
>> _replicator? It seems like even _users might at some point be in an
>> unsupported on-disk version. I run all of my couches in Admin Party
>> mode so I never even look at the _users database, but it probably
>> wouldn't work all that well.
>>
>> Cheers,
>>
>> Dirkjan
>
> Hi Dirkjan,
>
> Your probably right about the user migrations. Basically if your use
> document doesn't have any owner doc a normal user won't be abble to
> update it. On the other hand it should still be possible to
> update/delete them with an admin.
>
>
> Can ou create separate issues about this on jira ? (one for migration
> , and the other for the users db migration) ? It will help to track
> the problem.
>
> - benoît

Re: Backwards compatibility

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Apr 10, 2012 at 10:15 AM, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 08:54, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Tue, Apr 10, 2012 at 6:47 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>>> On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> Your probably right about the user migrations. Basically if your use
>>>> document doesn't have any owner doc a normal user won't be abble to
>>>> update it. On the other hand it should still be possible to
>>>> update/delete them with an admin.
>>>>
>>>> Can ou create separate issues about this on jira ? (one for migration
>>>> , and the other for the users db migration) ? It will help to track
>>>> the problem.
>>>
>>> Sorry, not sure what you mean here.
>> the ml isn't really the right way to report an issue. opening a ticket
>> is definitely better. It helps to tracks achievements.
>
> You mean like badges??!?!?

achievement: the act of achieving : accomplishment

but this idea of badges is interesting ;)

- benoît

Re: Backwards compatibility

[Randall Leeds <ra...@gmail.com>]

On Tue, Apr 10, 2012 at 08:54, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 6:47 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau <bc...@gmail.com> wrote:
>>> Your probably right about the user migrations. Basically if your use
>>> document doesn't have any owner doc a normal user won't be abble to
>>> update it. On the other hand it should still be possible to
>>> update/delete them with an admin.
>>>
>>> Can ou create separate issues about this on jira ? (one for migration
>>> , and the other for the users db migration) ? It will help to track
>>> the problem.
>>
>> Sorry, not sure what you mean here.
> the ml isn't really the right way to report an issue. opening a ticket
> is definitely better. It helps to tracks achievements.

You mean like badges??!?!?

Re: Backwards compatibility

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Apr 10, 2012 at 6:47 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau <bc...@gmail.com> wrote:
>> Your probably right about the user migrations. Basically if your use
>> document doesn't have any owner doc a normal user won't be abble to
>> update it. On the other hand it should still be possible to
>> update/delete them with an admin.
>>
>> Can ou create separate issues about this on jira ? (one for migration
>> , and the other for the users db migration) ? It will help to track
>> the problem.
>
> Sorry, not sure what you mean here.
the ml isn't really the right way to report an issue. opening a ticket
is definitely better. It helps to tracks achievements.

Re: Backwards compatibility

[Dirkjan Ochtman <di...@ochtman.nl>]

On Mon, Apr 9, 2012 at 15:41, Benoit Chesneau <bc...@gmail.com> wrote:
> Your probably right about the user migrations. Basically if your use
> document doesn't have any owner doc a normal user won't be abble to
> update it. On the other hand it should still be possible to
> update/delete them with an admin.
>
> Can ou create separate issues about this on jira ? (one for migration
> , and the other for the users db migration) ? It will help to track
> the problem.

Sorry, not sure what you mean here.

Cheers,

Dirkjan

Re: Backwards compatibility

[Benoit Chesneau <bc...@gmail.com>]

On Mon, Apr 9, 2012 at 9:16 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Mon, Apr 9, 2012 at 15:12, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> I was just trying to upgrade the first of my servers to 1.2, and it
>> wasn't that pretty. As I understand it, compatibility with pre-0.10.0
>> databases has been dropped. However, this isn't mentioned in the
>> release notes, nor in the Breaking changes. Thus, I had to downgrade
>> to 1.1.1, compact a database and install 1.2.0 again. This is just a
>> PITA, and it seems fairly trivial that something like this should be
>> in the release notes and in the breaking changes.
>
> Forgot to mention something I'm not sure is an issue, but should be
> checked: how resistant is CouchDB against inaccessible _users or
> _replicator? It seems like even _users might at some point be in an
> unsupported on-disk version. I run all of my couches in Admin Party
> mode so I never even look at the _users database, but it probably
> wouldn't work all that well.
>
> Cheers,
>
> Dirkjan

Hi Dirkjan,

Your probably right about the user migrations. Basically if your use
document doesn't have any owner doc a normal user won't be abble to
update it. On the other hand it should still be possible to
update/delete them with an admin.


Can ou create separate issues about this on jira ? (one for migration
, and the other for the users db migration) ? It will help to track
the problem.

- benoît

Re: Backwards compatibility

[Dirkjan Ochtman <di...@ochtman.nl>]

On Mon, Apr 9, 2012 at 15:12, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> I was just trying to upgrade the first of my servers to 1.2, and it
> wasn't that pretty. As I understand it, compatibility with pre-0.10.0
> databases has been dropped. However, this isn't mentioned in the
> release notes, nor in the Breaking changes. Thus, I had to downgrade
> to 1.1.1, compact a database and install 1.2.0 again. This is just a
> PITA, and it seems fairly trivial that something like this should be
> in the release notes and in the breaking changes.

Forgot to mention something I'm not sure is an issue, but should be
checked: how resistant is CouchDB against inaccessible _users or
_replicator? It seems like even _users might at some point be in an
unsupported on-disk version. I run all of my couches in Admin Party
mode so I never even look at the _users database, but it probably
wouldn't work all that well.

Cheers,

Dirkjan