From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH v5 07/12] lib: introduce json_path_normalize routine References: <134d5b3da2e0d0102287cceb4d347c88ef2616b5.1540795996.git.kshcherbatov@tarantool.org> <20181101152200.GH30032@chai> <88101bba-75d3-0c44-a0af-fb4d66b1945d@tarantool.org> <20181120151303.34fstx2vcjzirbiz@esperanza> From: Kirill Shcherbatov Message-ID: Date: Mon, 26 Nov 2018 13:50:16 +0300 MIME-Version: 1.0 In-Reply-To: <20181120151303.34fstx2vcjzirbiz@esperanza> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Vladimir Davydov Cc: Kostya Osipov List-ID: > TBO I find the idea that we have to normalize json paths just to compare > them a bit of an overkill. Why not simply introduce json_path_cmp() and > use it instead? All those functions using key_part_path_cmp() are cold > paths so that wouldn't degrade performance. Ugum, now we use a new json_path_cmp routine in such scenarios. This allows us to use paths in form that user has specified. It is an interesting moment affecting error handling. The first path specified for routine is assumed to be valid. When the second path contains an error, the first path is assumed to be greater. In fact, this means that we catch an info that such paths are differ on index_def validations and error would raised during format creation, when path would be parsed manually next time. We have tests for this case.