[tarantool-patches] Re: [RFC 2/2] box/lua/console: Add support for lua output format

[Konstantin Osipov <kostja@tarantool.org>]

* Alexander Turenko <alexander.turenko@tarantool.org> [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