From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, Imeev Mergen <imeevma@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v8 2/3] sql: return all generated ids via IPROTO Date: Tue, 30 Oct 2018 17:30:26 +0300 [thread overview] Message-ID: <6167E418-CCCC-4596-9E6C-F04C02045456@tarantool.org> (raw) In-Reply-To: <53b98187eba28a890db153e97d9c0a2b3759d1dd.1540832830.git.imeevma@gmail.com> > On 29 Oct 2018, at 20:33, 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. I guess you should be more specific in describing such things. I don’t ask you to dive into details, but explaining main idea of implementation would definitely help reviewer to do his/her job. > > Closes #2618 > — > diff --git a/src/box/execute.c b/src/box/execute.c > index 24459b4..ebf3962 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/vdbe.h" > > > diff --git a/src/box/execute.h b/src/box/execute.h > index f21393b..614d3d0 100644 > --- a/src/box/execute.h > +++ b/src/box/execute.h > @@ -42,6 +42,7 @@ extern "C" { > /** Keys of IPROTO_SQL_INFO map. */ > enum sql_info_key { > SQL_INFO_ROW_COUNT = 0, > + SQL_INFO_GENERATED_IDS = 1, I vote for _AUTOINCREMENT_IDS, see comments below. Anyway, in JDBC it is called GENERATED_KEYS. So, we either follow JDBC convention or use our naming. In the latter case, AUTOINCREMENT_IDS sounds more solid. > sql_info_key_MAX, > }; > > /** > + * Append a new sequence value to Vdbe. List of automatically > + * generated identifiers is returned as metadata of SQL response. > + * > + * @param Vdbe VDBE to save id in. > + * @param id ID to save in VDBE. > + * @retval 0 Success. > + * @retval -1 Error. It looks terrible. Does this function really need comment at all? > + */ > +int > +vdbe_add_new_generated_id(struct Vdbe *vdbe, int64_t id); > > + > +int > +vdbe_add_new_generated_id(struct Vdbe *vdbe, int64_t id) > +{ > + assert(vdbe != NULL); > + struct id_entry *id_entry = region_alloc(&fiber()->gc, sizeof(*id_entry)); > + if (id_entry == NULL) { > + diag_set(OutOfMemory, sizeof(*id_entry), "region_alloc", "id_entry”); Out of 80. > + return -1; > + } > + id_entry->id = id; > + stailq_add_tail_entry(vdbe_generated_ids(vdbe), id_entry, link); > + return 0; > +} > + > /* > * Execute as much of a VDBE program as we can. > * This is the core of sqlite3_step(). > @@ -2995,8 +3015,9 @@ case OP_TransactionBegin: { > * If there is no active transaction, raise an error. > */ > case OP_TransactionCommit: { > - if (box_txn()) { > - if (box_txn_commit() != 0) { > + struct txn *txn = in_txn(); > + if (txn != NULL) { > + if (txn_commit(txn) != 0) { From first sigh it doesn’t look like diff related to patch. Add comment pointing out that txn_commit() doesn’t invoke fiber_gc() anymore and VDBE takes care of it. > /** > * Prepare given VDBE to execution: initialize structs connected > @@ -197,6 +198,15 @@ sql_alloc_txn(); > int > sql_vdbe_prepare(struct Vdbe *vdbe); > > +/** > + * Return pointer to list of generated ids. > + * > + * @param vdbe VDBE to get list of generated ids from. > + * @retval List of generated ids. > + */ > +struct stailq * > +vdbe_generated_ids(struct Vdbe *vdbe); As for me, “generated_ids” seems to be too general name… I would call it “autoincrement_ids" or sort of. > + > int sqlite3VdbeAddOp0(Vdbe *, int); > int sqlite3VdbeAddOp1(Vdbe *, int, int); > int sqlite3VdbeAddOp2(Vdbe *, int, int, int); > diff --git a/src/box/sql/vdbeInt.h b/src/box/sql/vdbeInt.h > index ce97f49..7a7d3de 100644 > --- a/src/box/sql/vdbeInt.h > +++ b/src/box/sql/vdbeInt.h > @@ -367,6 +367,11 @@ struct Vdbe { > struct sql_txn *psql_txn; > /** The auto-commit flag. */ > bool auto_commit; > + /** > + * List of ids generated in current VDBE. It is returned > + * as metadata of SQL response. > + */ > + struct stailq generated_ids; Again: “autoincrement_ids”. Term “generated_ids” can be confused with entity ids. For example, during execution of <CREATE TABLE> statement VDBE operates on space id, index id etc (IMHO). > > /* When allocating a new Vdbe object, all of the fields below should be > * initialized to zero or NULL > diff --git a/src/box/sql/vdbeaux.c b/src/box/sql/vdbeaux.c > index 6e42d05..ae73f25 100644 > --- a/src/box/sql/vdbeaux.c > +++ b/src/box/sql/vdbeaux.c > @@ -57,6 +57,7 @@ sqlite3VdbeCreate(Parse * pParse) > return 0; > memset(p, 0, sizeof(Vdbe)); > p->db = db; > + stailq_create(&p->generated_ids); > if (db->pVdbe) { > db->pVdbe->pPrev = p; > } > > @@ -2414,9 +2417,9 @@ sqlite3VdbeHalt(Vdbe * p) > * key constraints to hold up the transaction. This means a commit > * is required. > */ > - rc = box_txn_commit() == > - 0 ? SQLITE_OK : > - SQL_TARANTOOL_ERROR; > + rc = (in_txn() == NULL || > + txn_commit(in_txn()) == 0) ? > + SQLITE_OK : SQL_TARANTOOL_ERROR; > closeCursorsAndFree(p); > } > if (rc == SQLITE_BUSY && !p->pDelFrame) { > @@ -2780,6 +2783,8 @@ sqlite3VdbeDelete(Vdbe * p) > } > p->magic = VDBE_MAGIC_DEAD; > p->db = 0; > + if (in_txn() == NULL) > + fiber_gc(); Describe this change (in code, obviously): “VDBE is responsible for releasing region …" and so on. > sqlite3DbFree(db, p); > } > > diff --git a/src/box/txn.h b/src/box/txn.h > index e74c14d..87b55da 100644 > --- a/src/box/txn.h > +++ b/src/box/txn.h > @@ -49,6 +49,7 @@ struct engine; > struct space; > struct tuple; > struct xrow_header; > +struct Vdbe; > > enum { > /** > @@ -117,6 +118,19 @@ struct sql_txn { > * VDBE to the next in the same transaction. > */ > uint32_t fk_deferred_count; > + /** Current VDBE. */ > + struct Vdbe *vdbe; > +}; > + > +/** > + * An element of list of autogenerated ids, being returned as SQL > + * response metadata. > + */ > +struct id_entry { “id_entry” is too common name, be more specific pls. > + /** A link in a generated id list. */ > + struct stailq_entry link; > + /** Generated id. */ > + int64_t id; These comments are too obvious, they only contaminate source code. > }; > > /** > * FFI bindings: do not throw exceptions, do not accept extra > diff --git a/test/sql/iproto.result b/test/sql/iproto.result > index af474bc..af4fc12 100644 > --- a/test/sql/iproto.result > +++ b/test/sql/iproto.result > @@ -580,6 +580,98 @@ cn:close() > box.sql.execute('drop table test') > --- > ... > +-- gh-2618 Return generated columns after INSERT in IPROTO. > +-- Return all ids generated in current INSERT statement. Add pls case where generated ids are less than 0.
next prev parent reply other threads:[~2018-10-30 14:30 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-29 17:33 [tarantool-patches] [PATCH v8 0/3] " imeevma 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 1/3] box: factor fiber_gc out of txn_commit imeevma 2018-10-30 14:30 ` [tarantool-patches] " n.pettik 2018-10-30 19:15 ` Vladislav Shpilevoy 2018-10-30 20:03 ` Vladislav Shpilevoy 2018-10-30 20:06 ` Vladislav Shpilevoy 2018-10-30 21:32 ` Vladislav Shpilevoy 2018-10-30 23:08 ` n.pettik 2018-10-31 9:18 ` Vladislav Shpilevoy 2018-10-31 9:30 ` n.pettik 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 2/3] sql: return all generated ids via IPROTO imeevma 2018-10-30 14:30 ` n.pettik [this message] 2018-11-02 18:52 ` [tarantool-patches] " Imeev Mergen 2018-11-09 7:51 ` n.pettik 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 3/3] sql: remove psql_txn from Vdbe imeevma 2018-10-30 14:30 ` [tarantool-patches] " n.pettik 2018-10-30 19:41 ` Vladislav Shpilevoy 2018-11-09 8:02 ` [tarantool-patches] Re: [PATCH v8 0/3] sql: return all generated ids via IPROTO Kirill Yukhin
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=6167E418-CCCC-4596-9E6C-F04C02045456@tarantool.org \ --to=korablev@tarantool.org \ --cc=imeevma@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH v8 2/3] 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