From dev-return-48979-archive-asf-public=cust-asf.ponee.io@couchdb.apache.org Thu Jan 16 18:31:08 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id CB3F518060E for ; Thu, 16 Jan 2020 19:31:07 +0100 (CET) Received: (qmail 23449 invoked by uid 500); 16 Jan 2020 18:31:06 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 23436 invoked by uid 99); 16 Jan 2020 18:31:06 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jan 2020 18:31:06 +0000 Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 4F2FD1077 for ; Thu, 16 Jan 2020 18:31:06 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 8143B21FB6 for ; Thu, 16 Jan 2020 13:31:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 16 Jan 2020 13:31:05 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdehgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggffuffkfhgjvffosehtqh hmtdhhtdejnecuhfhrohhmpeftohgsvghrthcupfgvfihsohhnuceorhhnvgifshhonhes rghprggthhgvrdhorhhgqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppe ekledrvdefkedrudehgedrvddvleenucfrrghrrghmpehmrghilhhfrhhomheprhhnvgif shhonhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqleefgedvtddvjedvqd duudelgeejtdejjedqrhhnvgifshhonheppegrphgrtghhvgdrohhrghesfhgrshhtmhgr ihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [10.0.3.191] (unknown [89.238.154.229]) by mail.messagingengine.com (Postfix) with ESMTPA id 0146B80066 for ; Thu, 16 Jan 2020 13:31:05 -0500 (EST) From: Robert Newson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 16 Jan 2020 18:31:03 +0000 Subject: Re: FDB: Map index key/value limits Message-Id: <86B05055-0D0E-412D-8A0B-1D26F7238B07@apache.org> References: <469A0404-DA3B-4374-AC9F-704E86FB9B7C@apache.org> In-Reply-To: To: dev@couchdb.apache.org X-Mailer: iPhone Mail (16G140) Option A matches our behaviour for other (persistent) errors during indexing= and gets my vote.=20 Surfacing view build errors (option C) is certainly better but is obviously m= ore work.=20 > On 16 Jan 2020, at 16:09, Adam Kocoloski wrote: >=20 > Right. I sort of assumed an additional endpoint, something like >=20 > GET /db/_design/ddoc/_errors >=20 > Adam >=20 >> On Jan 16, 2020, at 10:56 AM, Garren Smith wrote: >>=20 >> Option A is similar to what we do currently when a doc fails to be mapped= >> and a user/admin would see the errors in the log. >>=20 >> Keeping an index is a nice idea, >> But what do we do with it? How would we expose that to the user? I=E2=80=99= m >> guessing we would have to add a new api endpoint or add it to the _info >> endpoint >>=20 >>=20 >>> On Thu, Jan 16, 2020 at 5:35 PM Adam Kocoloski wro= te: >>>=20 >>> Option C - keep a separate index of document IDs that failed indexing. >>>=20 >>> I could be convinced of either Option C or Option A, and tentatively agr= ee >>> with Paul that the document indexing ought to be atomic for an entire vi= ew >>> group. >>>=20 >>> Adam >>>=20 >>>> On Jan 16, 2020, at 9:48 AM, Paul Davis >>> wrote: >>>>=20 >>>> For A you also want to consider multiple emitted K/Vs on whether we >>>> index some or none. I'd assume none as that would match the existing >>>> equivalent of a doc throwing an exception during indexing. >>>>=20 >>>>> On Thu, Jan 16, 2020 at 8:45 AM Garren Smith wrote= : >>>>>=20 >>>>> Hi Everyone, >>>>>=20 >>>>> We want to impose limits on the size of keys and values for map indexe= s. >>>>> See the RFC for full details - >>>>> https://github.com/apache/couchdb-documentation/pull/410 >>>>>=20 >>>>> The question I have is what is the best user experience if the user do= es >>>>> exceed the key or value limit? >>>>>=20 >>>>> Option A - Do not index the key/value and log the error >>>>>=20 >>>>> Option B - Throw an error and don't build the index >>>>>=20 >>>>> Option C - Any other ideas? >>>>>=20 >>>>> Cheers >>>>> Garren >>>=20 >>>=20 >=20