couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Marino <mmar...@gmail.com>
Subject Re: Considering CouchDB
Date Wed, 20 Nov 2013 23:11:36 GMT
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind


Depends on your use case, I don't think it's any more hackey than
cron/curl. Crontab is good for scheduling, but if you want to refresh the
view depending on what *actually* arrives in the db, you can use
notifications:

http://wiki.apache.org/couchdb/Example%2520usages%2520of%2520DbUpdateNotification

I have used os daemons to do it, too, but notifications are cleaner.

On Nov 20, 2013 2:57 PM, "Robert Newson" <rnewson@apache.org> wrote:

The bigcouch merge will not bring any automatic view updating

scheduler. Nothing stops someone contributing one, of course.


B.



On 20 November 2013 22:49, Mike Marino <mmarino@gmail.com> wrote:

There are, of course, ways to get couchdb to update views dependent on

writes. I also believe this is supposed to get easier in the future

(included in the bigcouch merge?).


Am 20.11.2013 um 23:46 schrieb Simon Metson <simon@cloudant.com>:


Nope, views are updated on read, hence the "blocking" behaviour you

describe. You can query with update_after, which returns the stale index

then triggers the update.



On Wednesday, 20 November 2013 at 22:43, Mark Hahn wrote:


I thought that every write triggered a view rebuild and that the stale

option only meant a read didn't have to wait for a current rebuild to

finish. That would means the views are pretty much up-to-date.



On Wed, Nov 20, 2013 at 2:36 PM, Robert Newson <rnewson@apache.org>

wrote:


True, but remember couchdb doesn't automatically keep indexes fresh in

the background, so "stale" can be "really really stale". ;)


B.



On 20 November 2013 22:34, Simon Metson <simon@cloudant.com> wrote:

Unless your app can deal with querying the view stale.



On Wednesday, 20 November 2013 at 21:56, Mark Hahn wrote:


I meant http view requests were blocked. It is waiting for the view

rebuild.


I'm can't type what I'm thinking today.



On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn <mark@reevuit.com>

wrote:


never mind. I wasn't talking about the file level at all. I meant

that

http read requests are blocked after http update requests.



On Wed, Nov 20, 2013 at 1:52 PM, Robert Newson <rnewson@apache.org


wrote:


"DB reads are blocked by DB updates at the http level."


Nope, there's a process that can read the database and a separate

one

for writing to it. Writing to an append only file is obviously

serialized but there's no need to block reads.


B.



On 20 November 2013 21:35, Mark Hahn <mark@reevuit.com> wrote:

Database writes are not coupled to view updates.




I understand now, you are talking about file read/write level. DB

reads

are blocked by DB updates at the http level.



On Wed, Nov 20, 2013 at 1:05 PM, Robert Newson <

robert.newson@gmail.com

wrote:


"A write requires updating views and reads have to wait for the

update"


Is not true. Database writes are not coupled to view updates.


Sent from my iPad


On 20 Nov 2013, at 20:59, Mark Hahn <mark@reevuit.com> wrote:


A write requires updating views and reads have

to wait for the update

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message