Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: tarantool-patches@freelists.org, imeevma@tarantool.org
Subject: [tarantool-patches] Re: [PATCH v5 1/1] sql: return all generated ids via IPROTO
Date: Wed, 3 Oct 2018 22:19:48 +0300	[thread overview]
Message-ID: <d115efff-d3f4-184d-781e-a0912e0a4a2b@tarantool.org> (raw)
In-Reply-To: <23421254ee60958d4583af90100d77b222eb2aad.1538153530.git.imeevma@gmail.com>

Hi! Thanks for the patch!

I see that Kostja slightly reviewed it and you did not
answer him, so I inlined here some of his comments to
agree/disagree with them.

See 8 comments below.

On 28/09/2018 19:53, imeevma@tarantool.org wrote:
> According to documentation some JDBC functions have an ability to
> return all ids that were generated in executed INSERT statement.
> This patch gives a way to implement such functionality.
> 
> Closes #2618
> ---
> Branch: https://github.com/tarantool/tarantool/tree/imeevma/gh-2618-return-all-generated-ids
> Issue: https://github.com/tarantool/tarantool/issues/2618
> 
>   src/box/execute.c        | 24 ++++++++++++++++
>   src/box/execute.h        |  1 +
>   src/box/lua/net_box.c    | 21 ++++++++++++--
>   src/box/sequence.c       | 29 ++++++++++++++++++++
>   src/box/sql/vdbe.c       |  2 +-
>   src/box/sql/vdbe.h       |  3 +-
>   src/box/sql/vdbeInt.h    |  3 ++
>   src/box/sql/vdbeaux.c    | 15 ++++++++--
>   src/box/txn.h            | 13 +++++++++
>   test/sql/iproto.result   | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
>   test/sql/iproto.test.lua | 15 ++++++++++
>   11 files changed, 190 insertions(+), 7 deletions(-)
> 
> diff --git a/src/box/execute.c b/src/box/execute.c
> index 24459b4..d9fe33f 100644
> --- a/src/box/execute.c
> +++ b/src/box/execute.c
> @@ -42,6 +42,7 @@
>   #include "schema.h"
>   #include "port.h"
>   #include "tuple.h"
> +#include "sql/vdbeInt.h"

1. Kostja said:

>> Ugh. You're including a header which ends with Int. Have you
>> thought what this Int means? It's not Integer.

Strictly speaking, I agree with him. Src/box/execute is not
an SQL internal file. It even uses SQLite public API to
fetch names and types. I guess, you should implement a getter
for ids list like

     const struct stailq *
     vdbe_auto_ids_list(const struct Vdbe *v);

>   
>   const char *sql_type_strs[] = {
>   	NULL,
> @@ -639,14 +640,37 @@ err:
>   		assert(port_tuple->size == 0);
>   		if (iproto_reply_map_key(out, 1, IPROTO_SQL_INFO) != 0)
>   			goto err;
> +		struct stailq *id_list = &((struct Vdbe *)stmt)->id_list;
> +		uint64_t id_count = 0;
>   		int changes = sqlite3_changes(db);
>   		int size = mp_sizeof_uint(SQL_INFO_ROW_COUNT) +
>   			   mp_sizeof_uint(changes);
> +		if (stailq_empty(id_list) == 0) {

2. Kostja said:

>> What is the point of this == 0? Why are you comparing with an
>> integer here, not boolean? 

I partially agree and I guess it is my fault that I am too harsh
about code style. You used here == 0 because stailq_empty()
returns an integer, but its name looks like a flag getter, so you
can use it as a boolean here.

> +			struct id_entry *id_entry;
> +			stailq_foreach_entry(id_entry, id_list, link) {
> +				size += id_entry->id >= 0 ?
> +					mp_sizeof_uint(id_entry->id) :
> +					mp_sizeof_int(id_entry->id);
> +				id_count++;
> +			}
> +			size += mp_sizeof_uint(SQL_INFO_GENERATED_IDS) +
> +				mp_sizeof_array(id_count);
> +		}>   		char *buf = obuf_alloc(out, size);
>   		if (buf == NULL) {
>   			diag_set(OutOfMemory, size, "obuf_alloc", "buf");
>   			goto err;
>   		}
> +		if (id_count > 0) {

3. Lets be consistent: either you use !stailq_empty() in both
places, or id_count > 0.

> +			buf = mp_encode_uint(buf, SQL_INFO_GENERATED_IDS);
> +			buf = mp_encode_array(buf, id_count);
> +			struct id_entry *id_entry;
> +			stailq_foreach_entry(id_entry, id_list, link) {
> +				buf = id_entry->id >= 0 ?
> +				      mp_encode_uint(buf, id_entry->id) :
> +				      mp_encode_int(buf, id_entry->id);
> +			}
> +		}
>   		buf = mp_encode_uint(buf, SQL_INFO_ROW_COUNT);
>   		buf = mp_encode_uint(buf, changes);
>   	}
> diff --git a/src/box/lua/net_box.c b/src/box/lua/net_box.c
> index a928a4c..5d2ac78 100644
> --- a/src/box/lua/net_box.c
> +++ b/src/box/lua/net_box.c
> @@ -671,11 +671,28 @@ netbox_decode_sql_info(struct lua_State *L, const char **data)
>   	/* Only SQL_INFO_ROW_COUNT is available. */
>   	assert(map_size == 1);

4. How does it work? map_size can be 2 now, and the comment is
outdated - not only SQL_INFO_ROW_COUNT is available.

>   	(void) map_size;
> +	lua_newtable(L);
>   	uint32_t key = mp_decode_uint(data);
> +	/*
> +	 * If SQL_INFO_GENERATED_IDS in data then it should be
> +	 * just before SQL_INFO_ROW_COUNT.
> +	 */
> +	if (key == SQL_INFO_GENERATED_IDS) {
> +		uint64_t count = mp_decode_array(data);
> +		assert (count > 0);
> +		lua_createtable(L, 0, count);
> +		lua_setfield(L, -2, "generated_ids");
> +		lua_getfield(L, -1, "generated_ids");
> +		for (uint32_t j = 0; j < count; ++j) {
> +			int64_t value = mp_decode_uint(data);
> +			lua_pushinteger(L, value);
> +			lua_rawseti(L, -2, j + 1);
> +		}
> +		lua_pop(L, 1);
> +		key = mp_decode_uint(data);
> +	}
>   	assert(key == SQL_INFO_ROW_COUNT);
> -	(void) key;
>   	uint32_t row_count = mp_decode_uint(data);
> -	lua_createtable(L, 0, 1);
>   	lua_pushinteger(L, row_count);
>   	lua_setfield(L, -2, "rowcount");
>   }
> diff --git a/src/box/sequence.c b/src/box/sequence.c
> index 35b7605..ed6b2da 100644
> --- a/src/box/sequence.c
> +++ b/src/box/sequence.c
> @@ -38,6 +38,7 @@
>   #include <small/mempool.h>
>   #include <msgpuck/msgpuck.h>
>   
> +#include "txn.h"
>   #include "diag.h"
>   #include "error.h"
>   #include "errcode.h"
> @@ -178,6 +179,30 @@ sequence_update(struct sequence *seq, int64_t value)
>   	return 0;
>   }
>   
> +/**
> + * Save generated id in VDBE.
> + *
> + * @param value ID to save in VDBE.
> + * @retval 0 Success.
> + * @retval -1 Error.
> + */
> +static inline int
> +add_new_id_in_vdbe(int64_t value)

5. Kostja said:

>> subject-verb-object
I agree. He means 'vdbe_add_new_id'. And in such a
case it is evidently a part of Vdbe API, so put it into
vdbe.h with this signature:

     int
     vdbe_add_new_auto_id(struct Vdbe *vdbe, int64_t id);

> +{
> +	struct txn *txn = in_txn();
> +	if (txn == NULL || txn->psql_txn == NULL)
> +		return 0;
> +	assert(txn->psql_txn->vdbe != NULL);
> +	struct id_entry *id_entry = malloc(sizeof(*id_entry));
> +	if (id_entry == NULL) {
> +		diag_set(OutOfMemory, sizeof(*id_entry), "malloc", "id_entry");
> +		return -1;
> +	}
> +	id_entry->id = value;
> +	stailq_add_tail_entry(txn->psql_txn->id_list, id_entry, link);

6. If you have Vdbe, you do not need to store the list both in
Vdbe and sql_txn. Store it in Vdbe only.

7. Kostja said:

>> Why malloc?
It is understandable why malloc - txn after commit invalidates
the region memory. We neither can save ids on obuf directly
since while getting next id a yield is possible and the obuf
will be messed with another request.  But guess I thought up a
solution. It is a bit tricky, so maybe it should be accounted
as a separate issue and this solved with malloc.

I propose to split txn_commit() into commit and region reset.
Txn_commit() goal is to write data to disk, not to destroy a
region. It saves us when a transaction is started and committed
by Vdbe. But what about autocommit transactions? I think, we
should get rid of autocommit transactions for Vdbe. Vdbe always
starts a transaction for DML and commits it, but without region
reset - it is a part of vdbe finalize routine (which already
exists actually).

This split of txn_commit logic allows to store anything on
a region during Vdbe work and not being afraid about a reset.

> +	return 0;
> +}
> +
> diff --git a/src/box/sql/vdbe.h b/src/box/sql/vdbe.h
> index d5da5d5..9b94183 100644
> --- a/src/box/sql/vdbe.h
> +++ b/src/box/sql/vdbe.h
> @@ -179,10 +179,11 @@ Vdbe *sqlite3VdbeCreate(Parse *);
>    * Allocate and initialize SQL-specific struct which completes
>    * original Tarantool's txn struct using region allocator.
>    *
> + * @param vdbe VDBE that is being prepared or executed.
>    * @retval NULL on OOM, new psql_txn struct on success.
>    **/
>   struct sql_txn *
> -sql_alloc_txn();
> +sql_alloc_txn(struct Vdbe *vdbe);

8. I think, alloc should only alloc. sql_txn_begin should
put Vdbe into sql_txn.

  parent reply	other threads:[~2018-10-03 19:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 16:53 [tarantool-patches] " imeevma
2018-09-29  4:36 ` [tarantool-patches] " Konstantin Osipov
2018-10-18 11:29   ` Imeev Mergen
2018-10-03 19:19 ` Vladislav Shpilevoy [this message]
2018-10-04 22:31   ` Konstantin Osipov
2018-10-18 11:25   ` Imeev Mergen
2018-10-25 21:31     ` Vladislav Shpilevoy

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=d115efff-d3f4-184d-781e-a0912e0a4a2b@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=imeevma@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH v5 1/1] sql: return all generated ids via IPROTO' \
    /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