From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kshcherbatov@tarantool.org>
Subject: Re: [tarantool-patches] Re: [PATCH v3 5/7] memtx: rework memtx_tree
 to store arbitrary nodes
References: <cover.1550849496.git.kshcherbatov@tarantool.org>
 <9bc3c05ed8934b2d2ef00b6d570eafce4708c787.1550849496.git.kshcherbatov@tarantool.org>
 <20190225165758.z4tkrqts3lgio7be@esperanza>
From: Kirill Shcherbatov <kshcherbatov@tarantool.org>
Message-ID: <dcf9d4d6-f992-5c99-42f7-f3ea63f4dfa5@tarantool.org>
Date: Tue, 26 Feb 2019 15:10:10 +0300
MIME-Version: 1.0
In-Reply-To: <20190225165758.z4tkrqts3lgio7be@esperanza>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
To: tarantool-patches@freelists.org, Vladimir Davydov <vdavydov.dev@gmail.com>
List-ID: <tarantool-patches.dev.tarantool.org>

> This looks like encapsulation violation. Please either use
> MEMTX_TREE_ELEM_SET for this or introduce MEMTX_TREE_ELEM_CLEAR
> helper.
If we use MEMTX_TREE_ELEM_SET for this purpose, in case of hints we need this
additional check
-       (elem_ptr)->hint = tuple_hint(info, key_def);                           \
+       (elem_ptr)->hint = info != NULL ? tuple_hint(info, key_def) : 0;        \

So, let's introduce MEMTX_TREE_ELEM_CLEAR.

> How is this going to work for multikey indexes?
You may show kshch/gh-1257-multikey-index branch - there is a multikey indexes
prototype over patches that we are discuss.