couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: _global_changes purpose
Date Tue, 27 Jun 2017 15:55:23 GMT
The guarantee on the per-DB _changes feed is much stronger — if you got a 201 or 202 HTTP
response back on the updated documents will always show up in _changes eventually.

It'd be nice if we could offer the same guarantee on _db_updates but there are some non-trivial
technical challenges under the hood. In the current implementation you’d basically need
to crash the entire cluster within 1 second of the update being committed to the DB in order
for it to be lost from the _db_updates feed. I think that’s still a useful alternative to
opening up 100s of connections to listen to every database’s feed directly.

Cheers, Adam

> On Jun 27, 2017, at 2:42 AM, Vladimir Kuznetsov <vovanec@gmail.com> wrote:
> 
> Joan, thanks for the pointer to the documentation. 
> 
> Sorry for being annoying, I have one more question. The doc states the following:  
> 
> "Note: This was designed without the guarantee that a DB event will be persisted or ever
occur in the _db_updates feed. It probably will, but it isn't guaranteed". 
> 
> Ok, I understand events in _db_updates feed are not guaranteed to be in order, timing
is also is not guaranteed, that's fine. What makes me really confused is "DB event is not
guaranteed to ever occur in _db_updates feed". What's the point of using _db_updates if I
cannot rely on it? Recalling the use case you mentioned earlier in this thread: "you have
100 databases and you want to know when something changes on all of them", how do I know for
sure a change in some database occurred if it is not even guaranteed to eventually appear
in _db_updates?
> 
> Another question - is this true for per-db _changes feed i.e. is it also not guaranteed
that ANY change will eventually appear in _changes?
> 
> thanks,
> --Vovan
> 
>> On Jun 26, 2017, at 11:12 PM, Joan Touzet <wohali@apache.org> wrote:
>> 
>> I'll update the docs. However, for now we have:
>> 
>> ---
>> When a database is created, deleted, or updated, a corresponding event will be persisted
to disk (Note: This was designed without the guarantee that a DB event will be persisted or
ever occur in the _db_updates feed. It probably will, but it isn't guaranteed). Users can
subscribe to a _changes-like feed of these database events by querying the _db_updates endpoint.
>> 
>> When an admin user queries the /_db_updates endpoint, they will see the account name
associated with the DB update as well as update
>> ---
>> And technically, the endpoint can work without the _global_changes database, but
be aware:
>> 
>> ---
>> 3: global_changes, update_db: (true/false) A flag setting whether to update the global_changes
database. If false, changes will be lost and there will be no performance impact of global_changes
on the cluster.
>> ---
>> 
>> This is all from https://github.com/apache/couchdb-global-changes
>> 
>> I also learned something new today!
>> 
>> -Joan
>> 
>> ----- Original Message -----
>> From: "Vladimir Kuznetsov" <vovanec@gmail.com>
>> To: "Joan Touzet" <wohali@apache.org>
>> Cc: user@couchdb.apache.org
>> Sent: Tuesday, 27 June, 2017 1:53:02 AM
>> Subject: Re: _global_changes purpose
>> 
>> Thanks Joan. 
>> 
>> Very good to know. It'd be great to have this reflected somewhere in the official
couchdb 2.0 docs. Probably it is already there I just could not find that...
>> 
>> thanks,
>> --Vovan
>> 
>>> On Jun 26, 2017, at 10:42 PM, Joan Touzet <wohali@apache.org> wrote:
>>> 
>>> _db_updates is powered by the _global_changes database.
>>> 
>>> -Joan
>>> 
>>> ----- Original Message -----
>>> From: "Vladimir Kuznetsov" <vovanec@gmail.com>
>>> To: user@couchdb.apache.org, "Joan Touzet" <wohali@apache.org>
>>> Sent: Tuesday, 27 June, 2017 12:39:55 AM
>>> Subject: Re: _global_changes purpose
>>> 
>>> Hi Joan
>>> 
>>> I heard /_db_updates is the feed-like thing I could subscribe to listen to the
global updates(same way you described). It is not very clear why would I need access to _global_changes
database when I already have /_db_updates method with pagination and long-polling features.
>>> 
>>> Is listening on _global_changes's /_changes feed the same as listening on /_db_updates?
Or is there any difference? What is preferred?
>>> 
>>> thanks,
>>> --Vovan
>>> 
>>> 
>>>> On Jun 26, 2017, at 9:21 PM, Joan Touzet <wohali@apache.org> wrote:
>>>> 
>>>> Say you have 100 databases and you want to know when something changes on
all
>>>> of them. In 1.x you have to open 100 _changes continuous feeds to get that
>>>> information. In 2.x you have to open a single connection to _global_changes.
>>>> 
>>>> Think of the possibilities.
>>>> 
>>>> -Joan
>>>> 
>>>> ----- Original Message -----
>>>> From: "Vladimir Kuznetsov" <vovanec@gmail.com>
>>>> To: user@couchdb.apache.org
>>>> Sent: Monday, 26 June, 2017 8:47:46 PM
>>>> Subject: _global_changes purpose
>>>> 
>>>> Hi guys
>>>> 
>>>> I cannot find any good explanation what's the purpose of _global_changes
system database in CouchDB 2.0. Can somebody please explain or provide some pointer?
>>>> 
>>>> thanks
>>>> --Vovan
>>> 
> 


Mime
View raw message