спасибо за пак!

Всем привет. Подскажите пожалуйста, умеет ли php-коннектор отдать ext-типы строкой?

В тарантул админ мы их явно кастим в строки в зависимости от типа

Я сам не php-шник. Коллега бьется... затык у него случился с этим. Я как-то не верю, что старый расширенный тип в широко используемом коннекторе не поддерживается

если нет, я бы готов на сишке что-то присунуть - знать бы куда :)

с неофициальным клиентом это выглядит как-то так:
https://github.com/basis-company/tarantool-admin/blob/master/php/Job/Space/Select.php#L47-L58

вот это ещё может быть полезным: https://github.com/tarantool-php/client#user-defined-types

спасибо

если речь про tarantool-php/client, то он из коробки поддерживает 2 кодировщика, оффициальный и неофициальный. по умолчанию используется неофициальный так как он более фичастый, например, поддерживает ext типы :) Если не задавать никаких кастомных обработчиков для типов, то при распаковке возвращается объект Ext с двумя полями - type (int) и data (binary string). То есть в $ext->data после распаковки будет лежать raw data вашего экстеншена (вот тут пример - https://github.com/rybakit/msgpack.php#extensions). Если речь про какие-то тарантуловские msgpack экстеншены, то, по умолчанию, клиент определяет какие есть доступные php модули, необходимые для поддержки расширений (например uuid или decimal) и на основе этого регистрирует обработчики. Авто регистрацию можно отключить, тогда всё будет распаковываться в Ext.

а можно попросить прокинуть настройку в докере
TARANTOOL_READONLY

Если приложение на Cartridge то вроде ж есть же: https://github.com/tarantool/cartridge/blob/cdd26786b0171fb51f044d9a555e11468d24c8ed/cartridge/argparse.lua#L147

@a_lyapunov рассказывает про новый менеджер транзакций в Tarantool 2.6  

https://habr.com/ru/company/mailru/blog/540842/

---

Для нового менеджера транзакций memtx мы сформировали список требований, которому не удовлетворяли ни текущая реализация транзакций memtx, ни менеджер транзакций vinyl:

1. Дешево по памяти и производительности по принципу «не используешь — не платишь». Если разные транзакции работают с непересекающимися данными, то хочется иметь обычную производительность, как без менеджера.

2. При пересекающихся множествах данных производительность также должна оставаться на достойном уровне.

3. Реализация должна быть максимально независимой от типа индекса.

4. Serializable без блокировок (то есть с абортами при конфликте), как в vinyl.

Но есть и проблемы. Подход, когда история чтения привязывается к кортежу, конечно, во многом хорош. Однако когда при чтении было обнаружено «ничего», такую историю просто некуда записывать, а записывать её надо для обнаружения конфликтов. Помимо этого в индексе типа TREE могут быть диапазонные чтения (от A до B) и чтения по неполным ключам. Для таких случаев приходится изобретать дополнительные индекс-зависимые структуры данных.

Я так вижу что это не сделано, gap locks не реализованы?

в коде по крайней мере я ничего с этим связанного не вижу

в релизе этого еще нет. в процессе ревью.

подход с отдельно стоящей хэш таблицей мне в целом нравится. его преимущество в том, что в неё можно положить не только версию, но и лок, и сделать полноценный SSI

мы с тобой это обсуждали.

ну и конечно хочется это видеть engine-agnostic, а не в кишках мемтикса