Tarantool development patches archive
 help / color / mirror / Atom feed
From: Kirill Shcherbatov <kshcherbatov@tarantool.org>
To: tarantool-patches@freelists.org,
	Konstantin Osipov <kostja@tarantool.org>
Cc: vdavydov.dev@gmail.com
Subject: Re: [tarantool-patches] Re: [PATCH v4 4/4] box: introduce functional indexes
Date: Thu, 25 Jul 2019 11:33:32 +0300	[thread overview]
Message-ID: <e3d493ee-6b55-aaae-1fe6-ddb7dc5a9144@tarantool.org> (raw)
In-Reply-To: <20190724215618.GC11790@atlas>

>> +	/**
>> +	 * Count of parts in functional index defintion.
>> +	 * All functional_part_count key_part(s) of an
>> +	 * initialized key def instance have func != NULL pointer.
>> +	 * != 0 iff it is functional index definition.
>> +	*/
>> +	uint32_t functional_part_count;
> 
> I don't get this comment, we don't store func pointer in key_part.
> Why do you need this at all? part_count should be enough.
In case of secondary key it's definition consists of two parts (produced with
key_def_merge) - functional index key parts that refer to hint_t memory and
tuple parts are specified in primary key.
   
>> +		if (index_opts->functional_fid > 0) {
>> +			lua_pushnumber(L, index_opts->functional_fid);
>> +			lua_setfield(L, -2, "func_id");
>> +		}
> 
> Why not function name?
Function name is not defined during recovery. I may print it in other cases, if it is ok for you

if (index_opts->func_id > 0) {
	lua_pushstring(L, "func");
	lua_newtable(L);

	lua_pushnumber(L, index_opts->func_id);
	lua_setfield(L, -2, "fid");

	lua_pushboolean(L, index_opts->is_multikey);
	lua_setfield(L, -2, "is_multikey");

	struct func *func = func_by_id(index_opts->func_id);
	if (func != NULL) {
		lua_pushstring(L, func->def->name);
		lua_setfield(L, -2, "name");
	}

	lua_settable(L, -3);
}

>> +static char *
>> +tuple_extract_key_stub(struct tuple *tuple, struct key_def *key_def,
>> +			     int multikey_idx, uint32_t *key_size)
>> +{
>> +	(void)tuple; (void)key_def; (void)multikey_idx; (void)key_size;
>> +	unreachable();
>> +	return NULL;
>> +}
>> +
>> +static char *
>> +tuple_extract_key_raw_stub(const char *data, const char *data_end,
>> +			   struct key_def *key_def, int multikey_idx,
>> +			   uint32_t *key_size)
>> +{
>> +	(void)data; (void)data_end;
>> +	(void)key_def; (void)multikey_idx; (void)key_size;
>> +	unreachable();
>> +	return NULL;
>> +}
> 
> Why do you need these?
> 

This code is really unreachable now. However this produce assertion error in case of
further invalid refactoring.

  reply	other threads:[~2019-07-25  8:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24  7:36 [PATCH v4 0/4] box: " Kirill Shcherbatov
2019-07-24  7:36 ` [PATCH v4 1/4] box: introduce tuple_chunk infrastructure Kirill Shcherbatov
2019-07-24  7:36 ` [PATCH v4 2/4] box: generalize memtx_multikey_tree methods Kirill Shcherbatov
2019-07-24 19:24   ` Konstantin Osipov
2019-07-24  7:36 ` [PATCH v4 3/4] box: refactor memtx_tree_delete_identical Kirill Shcherbatov
2019-07-24 19:24   ` Konstantin Osipov
2019-07-24  7:36 ` [PATCH v4 4/4] box: introduce functional indexes Kirill Shcherbatov
2019-07-24 12:24   ` [tarantool-patches] " Kirill Shcherbatov
2019-07-24 19:41   ` Konstantin Osipov
2019-07-24 20:04   ` Konstantin Osipov
2019-07-24 20:22   ` Konstantin Osipov
2019-07-25 11:20     ` [tarantool-patches] " Kirill Shcherbatov
2019-07-24 20:44   ` Konstantin Osipov
2019-07-25 11:22     ` [tarantool-patches] " Kirill Shcherbatov
2019-07-24 21:07   ` Konstantin Osipov
2019-07-25  8:27     ` [tarantool-patches] " Kirill Shcherbatov
2019-07-25  8:40       ` Konstantin Osipov
2019-07-25 11:18         ` Kirill Shcherbatov
2019-07-24 21:17   ` Konstantin Osipov
2019-07-24 21:56   ` Konstantin Osipov
2019-07-25  8:33     ` Kirill Shcherbatov [this message]
2019-07-24 12:25 ` [tarantool-patches] [PATCH v4 4/5] box: fix memtx_tree_index_build_array_deduplicate Kirill Shcherbatov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3d493ee-6b55-aaae-1fe6-ddb7dc5a9144@tarantool.org \
    --to=kshcherbatov@tarantool.org \
    --cc=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=vdavydov.dev@gmail.com \
    --subject='Re: [tarantool-patches] Re: [PATCH v4 4/4] box: introduce functional indexes' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox