Смотрите, в итоге история такая:
1. Нам нужно подгружать измерения SCD в кликхаус. Размером сотни ГБ
2. Вы посоветовали  словарь с движком ssd_cache,
3. мы увидели проблему в том что словари по доке не уме/т подкачивать инкрементально обновления (по строкам)
4. Вы написали что есть недокументированная фича update_field
5. В итоге мой коллега Николая подрубился сюда в чат и мы выяснили что  update_field для ssd_cache не работает в приницпе.

В итоге получается что словарь не подходит как способ из коробки  подтягивать SCD в КХ инкрементально, Правильно мы понимаем?

Смотрите, в итоге история такая:
1. Нам нужно подгружать измерения SCD в кликхаус. Размером сотни ГБ
2. Вы посоветовали  словарь с движком ssd_cache,
3. мы увидели проблему в том что словари по доке не уме/т подкачивать инкрементально обновления (по строкам)
4. Вы написали что есть недокументированная фича update_field
5. В итоге мой коллега Николая подрубился сюда в чат и мы выяснили что  update_field для ssd_cache не работает в приницпе.

В итоге получается что словарь не подходит как способ из коробки  подтягивать SCD в КХ инкрементально, Правильно мы понимаем?

Для ssd_cache не должно работать. Это бессмысленно.

Смотрите, в итоге история такая:
1. Нам нужно подгружать измерения SCD в кликхаус. Размером сотни ГБ
2. Вы посоветовали  словарь с движком ssd_cache,
3. мы увидели проблему в том что словари по доке не уме/т подкачивать инкрементально обновления (по строкам)
4. Вы написали что есть недокументированная фича update_field
5. В итоге мой коллега Николая подрубился сюда в чат и мы выяснили что  update_field для ssd_cache не работает в приницпе.

В итоге получается что словарь не подходит как способ из коробки  подтягивать SCD в КХ инкрементально, Правильно мы понимаем?

@dj_mixer сори, не вы. А вот уважаемый коллега сформулировал

После консультации с админами диагноз, что имеющуюся схему AD не натянуть на глобус текущей схемы работы LDAP с ролями/группами в clickhouse )

Вообще, натянуть можно даже на основании той информации, которую вы предоставили. Просто для каждой OU можно создать свой ldap_server. Но мне кажется, если вы ответите на мои вопросы в issue, то еще есть шанс прямого решения.

Кириллица в DN - не проблема.
Последним пообщением я просил аутпут этих:

dsquery user -name s.v.petrov
dsquery group -name users_l0.2

Кириллица в DN - не проблема.
Последним пообщением я просил аутпут этих:

dsquery user -name s.v.petrov
dsquery group -name users_l0.2

[In reply to Denis Glazachev]
кстати я тут упустил. Отдельный поиск ролей по ЛДАП тоже вообще не надо делать. вы просто должны взять из объекта пользователя атрибуты memberOf (configurable)

теперь я вспомнил почему у нас есть поддержка атрибута "memberOf"  =)

Ну так memberOf указывается в search filter.

не, если есть memberOfAttributeName ="memberOf"
можно без search filter, вообще не искать группы

Кириллица в DN - не проблема.
Последним пообщением я просил аутпут этих:

dsquery user -name s.v.petrov
dsquery group -name users_l0.2

да, и это будет частный случай

да, как раз на такие.. но в данном случае можно просто сделать улучшение с поддеркой placholder, {binddn:attr} / {fullbinddn}

Тут такая тема: в OU указана ссылка на DN пользователя (в той или иной форме, member, memberOf, и т.п.) Если по ней восстановить истинный DN где записан пользователь(ли), и его указать как bind_dn, то потом можно делать search по дереву груп с member=uid={user_name}