Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: error (athena.apache.org: local policy)
From: Jan Lehnardt <jan@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_F1993955-43B5-40EB-9034-1D5C794538AA";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <5FD58AC4-DC89-492C-9FC6-A4A101954022@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Erlang vs JavaScript
Date: Fri, 16 Aug 2013 17:54:50 +0200
References: 
 <CAPNuaCjQ3wgAd1BMyNUtip0rztK6n3Ex3rnq-hc=NXwL4Wt+pg@mail.gmail.com>
 <CAG+HO1ysanHLAYTh5XXuN=WO3RMsjxsY9c5nXjGiHy1n_m74mA@mail.gmail.com>
 <CAPNuaCjTS1+GAqx=WG0qjiP+3Rc06bXbSFDc9jdvHOOZwWY+3g@mail.gmail.com>
 <CAG+HO1x+L2rKTXaVcuu2_n0FQW_5CWZ7Jk5qo96-8OK-sRU7XA@mail.gmail.com>
 <CAPNuaCh5qK2YxS0txBicvrc4fnQCgrj5pVz=_M0xqXaKfQyYjg@mail.gmail.com>
 <CAG+HO1w+N_TxeroFpKwY+U=G2iC6eEU2QMDbV9aGgueDsZ5Bcg@mail.gmail.com>
 <CACLy94Uq9eafd_Q-LXV8b3aCipnHgMnaWdn2C1LjnvuMQ-csiA@mail.gmail.com>
 <33DF91AF-94FF-4205-A6A9-B99030A489DA@couchbase.com>
 <CACLy94VKDdQ6YMdaLV=SD+6QAW2mTBVXst_AaBCzJ=dSU5rKFw@mail.gmail.com>
 <47F84BCE-BBA0-490B-AE1D-DC70382A1320@couchbase.com>
 <CACLy94VTqy3twfDXF8e-zxh+-Au0mrip48NC=pWPAx9CV0e9JA@mail.gmail.com>
To: user@couchdb.apache.org
In-Reply-To: 
 <CACLy94VTqy3twfDXF8e-zxh+-Au0mrip48NC=pWPAx9CV0e9JA@mail.gmail.com>

--Apple-Mail=_F1993955-43B5-40EB-9034-1D5C794538AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I think it is worth putting Jason=92s and Jens=92s viewpoints on a scale =
of =93learning to live with the pain=94 and =93finding relief for the =
pain=94, where =93pain=94 is any of View Build Time or View Index Time =
from Jason=92s glossary.

If living with the pain works for you, Jason=92s point of view is very =
valuable because all you need to is accept the current situation :)

But I think it is also worth considering that there are scenarios where =
living with the pain is just not a fun or viable thing to do and then =
finding relief for the pain is a good strategy.

This thread started a fork on dev@ with concrete engineering suggestions =
on how to make this a reality in CouchDB, so please join us there if you =
want to help out.

Best
Jan
--


On Aug 16, 2013, at 17:24 , Jason Smith <jhs@apache.org> wrote:

> On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke <jens@couchbase.com> =
wrote:
>=20
>>=20
>> On Aug 15, 2013, at 10:14 AM, Jason Smith <jhs@apache.org> wrote:
>>=20
>>> To restate my final sentence which you quoted: Accessing a view is =
an
>> index
>>> scan, it hardly matters what the total data size is; therefore after =
the
>>> building period, all views are basically always instantly available.
>>=20
>> You=92re missing my point, Jason. Introducing an arbitrary =93building =
period=94
>> implies you don=92t care about the latency between a database update =
and when
>> it becomes visible in view queries. As I said, that may be allowable =
in
>> some types of applications, but definitely not all. To repeat my =
example,
>> an e-commerce customer is not going to tolerate any =93building =
period=94
>> longer than a second or two in between their clicking =93Add To Cart=94=
 and the
>> item showing up in their cart.
>>=20
>=20
> I agree. But a hypothetical "Add to cart" would only be one or two =
document
> updates. That will be reflected in a view query pretty quickly. The =
HTTP
> overhead is probably still the majority of the time spent; updating =
the
> view index to reflect the new cart will be negligible.
>=20
> Do we agree there? It occurs to me that you and I may work in =
different
> environments. Perhaps you are accustomed to much heavier update =
frequency
> than I.
>=20
> My own glossary:
>=20
> View build time: Building the views the first time you push a new =
design
> document into an existing database. Can take a very long time, but can =
be
> done "offline."
>=20
> View update time: The time it takes couch to update a view to reflect =
those
> updates which happened since either the view build, or the view update
> (whichever was more recent).
>=20
> To me, view update time is regrettable but for most applications
> (read-heavy) it is not much of a problem. View build time is not a =
concern
> because you can run it at your leisure and "promote" it to the true
> document ID using COPY. In most situations, native views solve a
> non-problem (although I've cited a few cromulent exceptions.)


--Apple-Mail=_F1993955-43B5-40EB-9034-1D5C794538AA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlIOS0oACgkQ7KW8t7uWVrA7fwCgoUr3pu/ukAF0xMR+JRVG9ORb
iJgAoItJOf3mbb0FTttMJnESc9stR6Z/
=qHQX
-----END PGP SIGNATURE-----

--Apple-Mail=_F1993955-43B5-40EB-9034-1D5C794538AA--