Tarantool development patches archive
 help / color / mirror / Atom feed
From: Chris Sosnin <k.sosnin@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v2] iproto: add an empty body to the unprepare response
Date: Wed, 4 Mar 2020 11:14:12 +0300	[thread overview]
Message-ID: <465B5192-A6D8-45BE-8FA7-627BA804E22D@tarantool.org> (raw)
In-Reply-To: <a262e047-b57c-8483-b157-5ece82660496@tarantool.org>

[-- Attachment #1: Type: text/plain, Size: 4147 bytes --]

Thank you for the review!

> 4 марта 2020 г., в 01:33, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> написал(а):
> 
> Hi! Thanks for the patch!
> 
> On 03/03/2020 17:16, Chris Sosnin wrote:
>> Absence of the body in the unprepare response forces users to perform
>> additional checks to avoid errors. Adding an empty body fixes this problem.
>> 
>> Closes #4769
>> ---
>> branch: https://github.com/tarantool/tarantool/tree/ksosnin/gh-4769-unprepare-response-body
>> issue: https://github.com/tarantool/tarantool/issues/4769
>> 
>> As Nikita suggested, I created box/iproto.test.lua, and basically
>> inserted wrappers for requests testing from box-py for future usage.
>> 
>> src/box/iproto.cc        | 17 ++++----
>> test/box/iproto.result   | 86 ++++++++++++++++++++++++++++++++++++++++
>> test/box/iproto.test.lua | 54 +++++++++++++++++++++++++
>> 3 files changed, 150 insertions(+), 7 deletions(-)
>> create mode 100644 test/box/iproto.result
>> create mode 100644 test/box/iproto.test.lua
>> 
>> diff --git a/src/box/iproto.cc b/src/box/iproto.cc
>> index f313af6ae..d5891391d 100644
>> --- a/src/box/iproto.cc
>> +++ b/src/box/iproto.cc
>> @@ -1781,20 +1781,23 @@ tx_process_sql(struct cmsg *m)
>> 	 */
>> 	out = msg->connection->tx.p_obuf;
>> 	struct obuf_svp header_svp;
>> +	if (is_unprepare) {
> 
> Looks like you don't need that flag anymore. Consider the diff:
> 
> ====================
> diff --git a/src/box/iproto.cc <http://iproto.cc/> b/src/box/iproto.cc <http://iproto.cc/>
> index d5891391d..28095f5b8 100644
> --- a/src/box/iproto.cc <http://iproto.cc/>
> +++ b/src/box/iproto.cc <http://iproto.cc/>
> @@ -1716,10 +1716,9 @@ tx_process_sql(struct cmsg *m)
> 	struct obuf *out;
> 	struct port port;
> 	struct sql_bind *bind = NULL;
> -	int bind_count = 0;
> +	int rc, bind_count = 0;
> 	const char *sql;
> 	uint32_t len;
> -	bool is_unprepare = false;
> 
> 	if (tx_check_schema(msg->header.schema_version))
> 		goto error;
> @@ -1771,7 +1770,12 @@ tx_process_sql(struct cmsg *m)
> 			uint32_t stmt_id = mp_decode_uint(&sql);
> 			if (sql_unprepare(stmt_id) != 0)
> 				goto error;
> -			is_unprepare = true;
> +			out = msg->connection->tx.p_obuf;
> +			if (iproto_reply_ok(out, msg->header.sync,
> +					    schema_version) != 0)
> +				goto error;
> +			iproto_wpos_create(&msg->wpos, out);
> +			return;
> 		}
> 	}
> 
> @@ -1781,23 +1785,17 @@ tx_process_sql(struct cmsg *m)
> 	 */
> 	out = msg->connection->tx.p_obuf;
> 	struct obuf_svp header_svp;
> -	if (is_unprepare) {
> -		if (iproto_reply_ok(out, msg->header.sync, schema_version) != 0)
> -			goto error;
> -		iproto_wpos_create(&msg->wpos, out);
> -		return;
> -	}
> 	/* Prepare memory for the iproto header. */
> 	if (iproto_prepare_header(out, &header_svp, IPROTO_HEADER_LEN) != 0) {
> 		port_destroy(&port);
> 		goto error;
> 	}
> -	if (port_dump_msgpack(&port, out) != 0) {
> -		port_destroy(&port);
> +	rc = port_dump_msgpack(&port, out);
> +	port_destroy(&port);
> +	if (rc != 0) {
> 		obuf_rollback_to_svp(out, &header_svp);
> 		goto error;
> 	}
> -	port_destroy(&port);
> 	iproto_reply_sql(out, &header_svp, msg->header.sync, schema_version);
> 	iproto_wpos_create(&msg->wpos, out);
> 	return;

The change with rc and avoiding code duplication is more about refactoring, should we apply
it here? As for the flag, the current code is well separated, all switch-cases perform the execution, 
everything after is about preparing the message to send.

Maybe it’s only me, but it looks cleaner without this diff, not to mention it produces the same code.
If you (or someone else) insist, however, I will apply it and resend.

I added one small change to the branch:
        out = msg->connection->tx.p_obuf;
-       struct obuf_svp header_svp;
        if (is_unprepare) {
	...
	}
+       struct obuf_svp header_svp;
        /* Prepare memory for the iproto header. */
        if (iproto_prepare_header(out, &header_svp, IPROTO_HEADER_LEN) != 0) {

This variable is not needed in case of unprepare, so we could declare it later.


[-- Attachment #2: Type: text/html, Size: 92978 bytes --]

  reply	other threads:[~2020-03-04  8:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 16:16 Chris Sosnin
2020-03-03 22:33 ` Vladislav Shpilevoy
2020-03-04  8:14   ` Chris Sosnin [this message]
2020-03-04 22:39     ` Vladislav Shpilevoy
2020-03-05  5:41 ` Kirill Yukhin
2020-03-05  8:41   ` Nikita Pettik
2020-03-06 17:27     ` Alexander Turenko
2020-03-06 19:58       ` Chris Sosnin
2020-03-06 20:39         ` Alexander Turenko
2020-03-07 22:02         ` Nikita Pettik
2020-03-08 17:13           ` Alexander Turenko
2020-03-15 15:34       ` Vladislav Shpilevoy
2020-03-17  8:04         ` Kirill Yukhin
2020-03-16 20:33 ` Konstantin Osipov

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=465B5192-A6D8-45BE-8FA7-627BA804E22D@tarantool.org \
    --to=k.sosnin@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v2] iproto: add an empty body to the unprepare response' \
    /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