From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 15 Oct 2018 20:27:12 +0300 From: Vladimir Davydov Subject: Re: [PATCH v4 01/14] box: refactor key_def_find routine Message-ID: <20181015172712.ab4yaagtgbaagmwe@esperanza> References: <603e181a38f0c1e6bb7fe9b4d5ddced9cba09855.1539244271.git.kshcherbatov@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <603e181a38f0c1e6bb7fe9b4d5ddced9cba09855.1539244271.git.kshcherbatov@tarantool.org> To: Kirill Shcherbatov Cc: tarantool-patches@freelists.org List-ID: On Thu, Oct 11, 2018 at 10:58:41AM +0300, Kirill Shcherbatov wrote: > Replaced key_def_find with a new key_def_contains_part routine > that checks if key_def contains specified part. In all cases > legacy key_def_find has been used for such purpose. New API > is more convenient for complex key_part that will appear with > JSON paths introduction. > > Part of #1012. Nitpicking: This isn't a part of the json index feature. It's merely a prerequisite, a tiny step toward. We use Needed for #1012 in this case (note, no dot after the issue number). Please fix here and everywhere else. > --- > src/box/key_def.c | 17 +++++++++-------- > src/box/key_def.h | 10 ++++------ > 2 files changed, 13 insertions(+), 14 deletions(-) > > diff --git a/src/box/key_def.c b/src/box/key_def.c > index 545b5da..67b517f 100644 > --- a/src/box/key_def.c > +++ b/src/box/key_def.c > @@ -483,16 +483,17 @@ key_def_decode_parts_160(struct key_part_def *parts, uint32_t part_count, > return 0; > } > > -const struct key_part * > -key_def_find(const struct key_def *key_def, uint32_t fieldno) > +bool > +key_def_contains_part(const struct key_def *key_def, > + const struct key_part *to_find) Actually key_def_find is used in SQL code (see 2.0) and since we're moving to trunk-based development, you'll have to leave it in the next version. You should probably introduce key_def_contains_part as a static helper in addition to key_def_find.