[Tarantool-patches] [PATCH v5 3/3] box: add SQL settings to _session_settings

[Mergen Imeev]

Sorry, forgot to answer one question. The answer below.

On Mon, Dec 30, 2019 at 03:38:13PM +0300, Mergen Imeev wrote:
> Hi! Thank you fore review! My answers below.
> 
> On Mon, Dec 30, 2019 at 01:21:28PM +0200, Nikita Pettik wrote:
> > On 27 Dec 17:05, imeevma at tarantool.org wrote:
> > > Part of #4511
> > > 
> > > @TarantoolBot document
> > > Title: _session_settings system space
> > > The _session_settings system space used to view or change session
> > > settings.
> > > 
> > > This space uses a new engine. This allows us to create tuples on
> > > the fly when the get() or select() methods are called. This
> > > engine does not support the insert(), replace(), and delete()
> > > methods. The only way to change the setting value is update(),
> > > which can only be used with the "=" operation.
> > 
> > Do you have instruction for developers how to insert to this space
> > new values and remove obsolete ones? Sooner or later we will have to
> > introduce new SQL settings and clean-up unused.
> >  
> There is no such instruction for now. I will write an
> article in our wiki a bit later.
> 
> > > Because space creates a tuple on the fly, it allows us to get a
> > > tuple without saving it anywhere. But this means that every time
> > > we get a tuple from this system space, it is a new tuple, even if
> > > they look the same:
> > > 
> > > tarantool> s = box.space._session_settings
> > > tarantool> name = 'sql_default_engine'
> > > tarantool> s:get({name}) == s:get({name})
> > > ---
> > > - false
> > > ...
> > > 
> > > Currently, this space contains only SQL settings, since the only
> > > session settings are SQL settings.
> > > 
> > > List of currently available session settings:
> > > 
> > > sql_default_engine
> > > sql_defer_foreign_keys
> > > sql_full_column_names
> > > sql_full_metadata
> > > sql_recursive_triggers
> > > sql_reverse_unordered_selects
> > 
> > Is user capable of setting default values for these options?
> >  
> No, at least for now. Even if user will be able to do this,
> the default value of setting is a global setting. At least
> until we will be able to differentiate users.
> 
> > > Debug build also have debug settings that could be obtained from
> > > this sysview:
> > > 
> > > sql_parser_trace
> > > sql_select_trace
> > > sql_trace
> > > sql_vdbe_addoptrace
> > > sql_vdbe_debug
> > > sql_vdbe_eqp
> > > sql_vdbe_listing
> > > sql_vdbe_trace
> > > sql_where_trace
> > 
> > Imho there are too many debug options. We can easily merge
> > half of them (where + select traces, vdbe eqp + debug).
I agree, but I suggest to leave this to the next release.
Should I create an issue?

> > What is more, I think different set of options on debug and
> > release builds is quite error prone. Mb it is worth keeping
> > debug options all the time, but disallow setting their values
> > to true?
> >
> It is possible, but I don’t think there will be problems,
> since there are no numerical identifiers. Still, I do not
> think that user should be able to see internal settings.