incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@hahnca.com>
Subject Re: Considering CouchDB
Date Wed, 20 Nov 2013 23:00:30 GMT
> .it sounds hackey.

Just use update_after.  It's not a hack.


On Wed, Nov 20, 2013 at 2:59 PM, Stanley Iriele <siriele2x3@gmail.com>wrote:

> 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
> 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