From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 22F644696C3 for ; Tue, 21 Apr 2020 22:03:29 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id z26so15132213ljz.11 for ; Tue, 21 Apr 2020 12:03:29 -0700 (PDT) Date: Tue, 21 Apr 2020 22:03:25 +0300 From: Konstantin Osipov Message-ID: <20200421190325.GA3677@atlas> References: <6d673bc4-c85b-219e-6ff4-79efc7627275@tarantool.org> <20200420080547.x5tttvnqcmplksp6@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200420080547.x5tttvnqcmplksp6@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH V6 00/10] Extending error functionality List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy * Kirill Yukhin [20/04/20 11:08]: > > It is still unfinished because of underdesigned traceback > > feature, because of payload absence. IMO, MP_EXT is also an > > overkill. Tuples live fine as MP_ARRAY, and they are the most > > used type. We should have gone for simple MP_MAP, without > > MP_EXT. Just a map. > > We already broken connectors by introducing UUID (w/ MP_EXT). UUID change was planned. This was not. UUID is a fundamental data type. struct error is just an object. This was a rushed up decision. Better revert it and go back to MP_MAP. > > It is worth mentioning separately, how hard it is to use the > > error marshaling now, because of this session setting. And > > there still is no way to enable the feature without touching > > the session, even if all my connectors support it. As I > > mentioned, enabling it for every session manually is a > > non-trivial task for a user. > > I guess we can switch it on by default in future releases. > > > But we have releases coming, so lets push all in whatever > > state it is, of course. > > -- > Regards, Kirill Yukhin -- Konstantin Osipov, Moscow, Russia