From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C4AD9246A6 for ; Wed, 28 Aug 2019 05:31:29 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntl3yYb4si55 for ; Wed, 28 Aug 2019 05:31:29 -0400 (EDT) Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 840D6245E6 for ; Wed, 28 Aug 2019 05:31:29 -0400 (EDT) Date: Wed, 28 Aug 2019 12:31:26 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 0/8] rfc: introduce dry-run execution of SQL queries Message-ID: <20190828093126.GB19848@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Nikita Pettik Cc: tarantool-patches@freelists.org, v.shpilevoy@tarantool.org, alexander.turenko@tarantool.org * Nikita Pettik [19/08/27 16:34]: > To execute query in dry-run mode locally separate method of box has been added: > box.dry_run("sql_string"). Current implementation does not modify box.execute() > making it accept third optional argument (except for array of bindings) - this > is to be discussed. If you have to use a separate method, call it "prepare", and return a prepare handle. The handle may simply contain SQL text as prepared state, + metadata. Let's not invent a new API, dry run is an implementation detail. > Other open (or dubious) questions. > > 1. How to handle DML queries. Meanwhile getting meta-information of DDL queries > is likely to be useless, calculating number of affected rows in case of DML > query can be sensible. On the other hand, it can turn out to be quite > non-trivial task. In its current state, box.dry_run("DML_Query") always > returns 0 as row count. IMHO it can be done but as a follow-up The point of dry-run in particular is to find out on the driver side whether the query returns a result set or not. So please handle them. > 2. Should dry_run() except for parsing also bind variables? I guess no, since > it results in byte-code (i.e. prepared statement) modification. On the other > hand, it allows setting correct type for bindings (see sql_bind_type()). By > default, all binding parameters have boolean type. No, dry-run is an alias to 'prepare', which doesn't return a prepare handle only because we decided to use SQL text as a prepared statement identifier, and hide an explicit prepared statement handle from the client. The prepared statement cache will be managed transparently by the server when it is added, for two reasons: - to not force this complication on the client - to be able to use prepared statements with statements which were not explicitly prepared. An important detail: for this reason, dry run should also return the number of parameter markers, their type and count. > 3. Interface for local call. In current implementation I've added box.dry_run() > in addition to traditional box.execute() method. Instead, we can make > box.execute() accept third argument as it is handled in net.box. Replied. I will look at the patch separately. -- Konstantin Osipov, Moscow, Russia