ydb/yt/cpp/mapreduce/interface/format.cpp, branch CLI_2.30.0

Support building yt/cpp and yt/yt/core with vanilla protobuf

2024-03-19T11:16:23Z

After this PR yt/cpp and yt/yt/core are possible to be built both with Arcadia protobuf (that uses TString as a string) and vanilla protobuf (that uses std::string as a string). To achieve so, a couple of interoperability primitives are introduced. * `TProtobufString` is an alias to protobuf string type, i.e. it can be `TString` or `std::string` depending on the protobuf implementation. * `IsVanillaProtobuf` and `IsArcadiaProtobuf` are the constexpr boolean values that allow to check protobuf implementation both in the compile time and runtime. The most challenging interoperability issue solved here is a string copy between protobuf message and C++ code that has a form of `TString str = msg.str()`. This code works perfect with Arcadia protobuf but does not work with vanilla protobuf. To solve it, a previously introduced primitive `FromProto` is used. This expression makes the most efficient cast possible between protobuf string and C++ string. Internally, it is just a copy in both cases. Since TString is CoW by default, this expression is almost zero-cost (actually it's just one atomic operation), so no degradation is expected for YTsaurus server builds. The most hot code is handled differently to avoid even atomic operations (see `GetRequestTargetYPath`). In case of vanilla protobuf string is copied, however there are no places in C++ SDK where it might be a problem. If such issues would appear, performance-critial code can be rewritten in `GetRequestTargetYPath`-style. --- 1a6f3e02cb6e83915102c24b73bc8734f6a48e74 Pull Request resolved: https://github.com/ytsaurus/ytsaurus/pull/466

Y_VERIFY->Y_ABORT_UNLESS at ^yt

2023-10-09T17:46:53Z

https://clubs.at.yandex-team.ru/arcadia/29404

[Sync from ytsaurus/ytsaurus] Added DSV format to client

2023-09-06T15:30:15Z

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en --- Pull Request resolved: #93

YT-19210: expose YQL shared library for YT.

2023-07-28T21:02:16Z

After this, a new target libyqlplugin.so appears. in open-source cmake build. Diff in open-source YDB repo looks like the following: https://paste.yandex-team.ru/f302bdb4-7ef2-4362-91c7-6ca45f329264

Revert "YT-19324: move YT provider to ydb/library/yql"

2023-06-30T08:13:34Z

This reverts commit ca272f12fdd0e8d5c3e957fc87939148f1caaf72, reversing changes made to 49f8acfc8b0b5c0071b804423bcf53fda26c7c12.

YT-19324: move YT provider to ydb/library/yql

2023-06-30T00:37:03Z

This commit is formed by the following script: https://paste.yandex-team.ru/6f92e4b8-efc5-4d34-948b-15ee2accd7e7/text. This commit has zero effect on all projects that depend on YQL. The summary of changes: - `yql/providers/yt -> ydb/library/yql/providers/yt `- the whole implementation of YT provider is moved into YDB code base for further export as a part of YT YQL plugin shared library; - `yql/providers/stat/{expr_nodes,uploader} -> ydb/library/yql/providers/stat/{expr_nodes,uploader}` - a small interface without implementation and the description of stat expr nodes; - `yql/core/extract_predicate/ut -> ydb/library/yql/core/extract_predicate/ut`; - `yql/core/{ut,ut_common} -> ydb/library/yql/core/{ut,ut_common}`; - `yql/core` is gone; - `yql/library/url_preprocessing -> ydb/library/yql/core/url_preprocessing`. **NB**: all new targets inside `ydb/` are under `IF (NOT CMAKE_EXPORT)` clause which disables them from open-source cmake generation and ya make build. They will be enabled in the subsequent commits.