[Tarantool-patches] [PATCH v2 07/16] port: add dump format and request type to port_sql

[Konstantin Osipov]

* Nikita Pettik <korablev at tarantool.org> [19/11/21 10:00]:
> Dump formats of DQL and DML queries are different: the last one contains

Ergh, this is not dump, but result set/serialization format. Dump
in SQL is usually used for logical or physical database
backup.

> number of affected rows and optionally list of autoincremented ids; the
> first one comprises all meta-information including column names of
> resulting set and their types. What is more, dump format is going to be
> different for execute and prepare requests. So let's introduce separate
> member to struct port_sql responsible for dump format to be used.
> 
> What is more, prepared statement finalization is required only for
> PREPARE-AND-EXECUTE requests. So let's keep request type in port as well.

> 
> Note that C standard specifies that enums are integers, but it does not
> specify the size. Hence, let's use simple uint8 - mentioned enums are
> small enough to fit into it.

enum sizeof in C and older C++ is implementation dependent.

what do you mean here?

> +	struct port_sql *port_sql = (struct port_sql *) base;
> +	if (port_sql->request == PREPARE_AND_EXECUTE)
> +		sql_finalize(((struct port_sql *)base)->stmt);

Does this work with the statement object only or with the cache as
well? 

I suggest we introduce a clear naming for API calls:

sql_stmt_* - for statement object api
sql_stmt_cache_* - for prepared statement api

sql_finalize, sql_prepare, sql_execute - for SQL high level API
which manipulates both statements and the cache.

What do you think?

> -port_sql_create(struct port *port, struct sql_stmt *stmt)
> +port_sql_create(struct port *port, struct sql_stmt *stmt,
> +		enum sql_dump_format dump_format, enum sql_request_type request)
>  {
>  	port_tuple_create(port);
> -	((struct port_sql *)port)->stmt = stmt;
>  	port->vtab = &port_sql_vtab;
> +	struct port_sql *port_sql = (struct port_sql *) port;
> +	port_sql->stmt = stmt;
> +	port_sql->dump_format = dump_format;

Let's use sql_result_set_format? Do you have to introduce this
enum ? This information can be derived from sql_request_type, no +
statement type, no? If yes, I suggest to have a function, which
returns it, rather than store.

> +/**
> + * One of possible formats used to dump msgpack/Lua.
> + * For details see port_sql_dump_msgpack() and port_sql_dump_lua().


> + */
> +enum sql_dump_format {
> +	DQL_EXECUTE = 0,
> +	DML_EXECUTE = 1,
> +	DQL_PREPARE = 2,
> +	DML_PREPARE = 3,
> +};

Neither the names of the members nor comments convey what is going
on here - looks like a simple matrix dml/dql * prepare/execute.
Having a couple of if statments is not such a big deal IMHO.

> +	/**
> +	 * Dump format depends on type of SQL query: DML or DQL;
> +	 * and on type of SQL request: execute or prepare.
> +	 */
> +	uint8_t dump_format;
> +	/** enum sql_request_type */
> +	uint8_t request;

If I had to add these constants, I would not use type-erasing
uint8 here, but use max value for enum in C/C++, which is 64 bits
and the original type. 

-- 
Konstantin Osipov, Moscow, Russia