From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 2561E452566 for ; Mon, 4 Nov 2019 20:36:55 +0300 (MSK) Received: by mail-pg1-f193.google.com with SMTP id q22so4161142pgk.2 for ; Mon, 04 Nov 2019 09:36:54 -0800 (PST) Date: Mon, 4 Nov 2019 20:36:51 +0300 From: Konstantin Osipov Message-ID: <20191104173651.GG29784@atlas> References: <33c2b63341c834ba5c4ff1173065b753e7f21937.1572565151.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33c2b63341c834ba5c4ff1173065b753e7f21937.1572565151.git.v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 3/3] tuple: rework updates to improve code extendibility List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [19/11/01 09:55]: > Before the patch update was implemented as a set of operations > applicable for arrays only. It was ok until field names and JSON > paths appearance, because tuple is array on the top level. > > But now there are four reasons to allow more complex updates of > tuple field internals via JSON paths: > * tuple field access by JSON path is allowed so for consistency > JSON paths should be allowed in updates as well; > * JSON indexes are supported. JSON update should be able to > change an indexed field without rewriting half of a tuple; > * Tarantool is going to support documents in storage so JSON > path updates is one more step forward; > * JSON updates are going to be faster than get + in-memory > Lua/connector update + replace (or update of a whole tuple > field). > > The patch prepares current update code to be extended by updates > of map, so named isolated 'bar' updates, and multilevel updates. > > The concept is to build a tree of update objects. Each updates a > scalar terminal value (leaf of that tree), or a complex object > like array or map. In the latter case these objects contain >= 2 > children updates. > > This organization allows to split update implementation into > several independent files-modules for each update type. Next > commits will introduce them one by one. I am fine with this patch but could you really extract the code split into a separate commit? I don't want to give minor comments on the changes you make besides the split, like changes in the comments, within the patch that does the split. Let's push the code split already. -- Konstantin Osipov, Moscow, Russia