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 8189D24676 for ; Tue, 9 Jul 2019 14:06:54 -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 NJzUhCHMS11o for ; Tue, 9 Jul 2019 14:06:54 -0400 (EDT) Received: from smtp21.mail.ru (smtp21.mail.ru [94.100.179.250]) (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 CDC51244E7 for ; Tue, 9 Jul 2019 14:06:53 -0400 (EDT) Date: Tue, 9 Jul 2019 21:06:50 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [RFC 2/2] box/lua/console: Add support for lua output format Message-ID: <20190709180650.GA12956@atlas> References: <20190705210959.8527-1-gorcunov@gmail.com> <20190705210959.8527-3-gorcunov@gmail.com> <20190705225908.GC30966@atlas> <20190706065002.GB4602@uranus.lan> <20190706160239.GA21719@atlas> <20190709034648.ngux4oxovmufsbhr@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190709034648.ngux4oxovmufsbhr@tkn_work_nb> 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: Alexander Turenko Cc: Cyrill Gorcunov , tml * Alexander Turenko [19/07/09 09:46]: > Related questions I'm tentative about: > > * Is there a way to keep an old session after reconnection? In theory we can delay destroying the session, but we wouldn't know for how long. > * Is there way to share a session for a connection pool? That would be absurd. the whole point of having a session is to have a private state. We plan to multiplex sessions in future with streams btw. > > Well, at least every new test should use the new output. There > > aren't that many results, and it's just results - not tests - so > > they won't be hard to merge (re-run the test and compare the > > diff). Besides, 1.10 is more or less frozen, it accepts only minor > > bugfixes. Now it's a perfect time. > > I guess the lua output format support will not be part of 1.10 branch? No, we could only add \set output keyword support there, but not the format itself. But there is very low risk of adding a new output there too - so up to you. > If we'll change all test result files, then cherry-picking anything > backward to 1.10 will require extra work. So I don't think we should > convert old result files. 1.10 is alive, so I doubt it actually can be > frozen. then let's add this to both branches. > Re using lua output for new test result files. We'll need to write an > output format into a result file header. This requires to bump a result > file format version and implement the new logic in test-run only for > them (I don't see other backward compatible ways for now). > > I'm also afraid that the inconsistency in result file formats (one of > which is not supported by 1.10) can give us problems if we'll decide to > backport something to 1.10 after it will land to master with a test in > the new format. > > So lua output by default for new tests seems to be doable feature, but > will increase complexity of our test harness and will possibly > problematic in some (rare?) cases. > > Are there any real problems with yaml result files? yes, the complexity of having too many result file format. Long term we don't need this complexity, it's a technical debt. Same applies to the current sql tests, most of them can be in plain sql. -- Konstantin Osipov, Moscow, Russia