Re: [Tarantool-patches] [PATCH v2 4/5] iproto: Add session settings for IPROTO

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

Thanks for the answers!

>>>>> @TarantoolBot document
>>>>>       Title: Add session_setting
>>>>
>>>> The doc request is corrupted, docbot won't understand that because
>>>> of leading whitespaces.
>>>>
>>>>> iproto_error_format setting has been added to _session_settings
>>>>
>>>> Looks like there is a lack of global setting similar to what we had
>>>> for tracebacks. Currently, when the option is false (by default), and
>>>> I want to use the new format everywhere, I need to find every single
>>>> place where I create a new session, and put there code saying
>>>>
>>>>       box.session.settings.error_format = new/old/whatever
>>>>
>>>> I think there should be a global option when a user's application is
>>>> ready to switch to the new format completely. Otherwise it is going
>>>> to be hell to find all places where a new session is created, and patch
>>>> them.
>>>>
>>>> Just a reminder - every fiber.new(), fiber.create() creates a session,
>>>> every iproto connection is a session.
>>> This was discussed in TPT chat with Mons and Nazarov, and after that with you, Turenko, Mons ... in zoom. I was orienteted by the net.box session and I might not know something. Where do you suggest storing the setting?
>>
>> Looks like you didn't understood me. I don't propose to remove the
>> session local option. I propose to provide an ability to override it
>> with a global option if necessary. So we have session option by
>> default with the old format, and global option unset.
>>
>> If someone is ready to start using new errors everywhere, he just turns
>> the global option on.
>>
>> If someone is not ready, he continues using session local option.
>>
>> Why that may be needed - I said above. Turning that option on for every
>> session is going to be very tricky. But maybe it can be moved to the next
>> release (the global option). Don't know. The issue is already a huge
>> blackhole which absorbed lots of independent initially unplanned
>> features. The more we move for later, the better.
>>
>> You should try to ask users in the red chat. It helps sometimes, they
>> can share their opinions and experience of upgrades. Just formulate your
>> question in a short but detailed manner, provide a couple of
>> ready-to-choose answers, probably a poll.
>>
> Ok. But for beginning, I need to understand where this flag can be
> located. I will think about that but if you have a proposal, please,
> write it.

box.cfg is a first option, but naive - error objects exist before box.cfg
is called.

I would go for box.error.cfg(). It would look fine - one place for configuring
traceback and serialization format.

>>>>> +        local ext_err_supported = version_at_least(remote.peer_version_id, 2, 4, 1)
>>>>
>>>> 3. This won't work in case it is an instance bootstrapped from the master
>>>> branch before 2.4.1 was released. I don't know how to fix it now.
>>> Sorry, I think this should not work until the release.
>>
>> Exactly for 'between-releases' users we introduced the new versioning schema
>> with 4 numbers. I don't think we can just say fuck off to them now. I
>> would better drop this from the patchset and added when somebody explicitly
>> asks for that, with good design and planning.
>>
> Ok.I have remove it, but:"Don't have 'between-releases' users a version more when previous release?"

First 3 numbers stay the same, and 4th is not transmitted to clients
(from what I remember). If correctly parsed your question, because
I am not sure I did.