Для стандартных bitmap-индексов патч не нужен, так как там длина ограничена в 64000 бита.
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
Чанки — всего лишь частный случай битовых строк.
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
Не нужно путать максимальную длину битовой строки вообще и длину чанка bitmap-индексов для таблиц в частности.
The maximum bitstring length is 262,104 bits (32763 x 8). источник
The third subscript contains a chunk number; for efficiency, bitmap indices are divided into a series of bitstrings each containing information for about 64000 rows from the table. Each of these bitstrings are referred to as a chunk. источник
Ещё можете посмотреть в исходниках значение $$$DeepSeeBitsPerChunk, BitsPerChunk, $$$BitMapSize.
Можете пояснить, что это за методы в GlobalsDB, которые могут вызывать функции Caché Object Script?
Скорее всего имелось в виду Globals API, а не GlobalsDB: Calling Caché Methods (Using the Globals API)
Ещё нужно учитывать, что не все возможности Globals API поддерживаются в GlobalsDB: Globals API In Caché
В своё время тоже делал свою реализацию протокола WebSocket средствами СУБД Caché, правда для 76 и 07 версии.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.
Вот правильная ссылка: www.microsoft.com/ru-ru/events/ep/vs2013_anounce/
Тот, за который отвечает сама Caché и который используется движком SQL и DeepSee (для MDX-запросов) для ускорения запросов.
А если свои bitmap-индексы будете использовать с длиной >64000 бит, то да — может пригодиться
Необязательно ждать новой версии, чтобы исправить ошибку в уже существующей.
По самой статье будут вопросы?
Чанки используются в таблицах для хранения bitmap/bitslice индексов и за их формированием и использованием следит сама система.
А битовые строки — это общий случай и Вы можете у себя в коде их использовать как угодно.
PS: есть мысль, что 64000 бита на чанк тянутся со времён, когда не было длинных строк. А для перехода на новую (большую) длину чанка требовалось бы перегенерировать индексы и подкорректировать пользовательский код, работающий с чанками напрямую, если там есть жёсткая привязка к такой длине. Возможно, когда-то в будущих версиях это и случится.
Ещё можете посмотреть в исходниках значение $$$DeepSeeBitsPerChunk, BitsPerChunk, $$$BitMapSize.
Не хватает где: на хабре или вообще?
Если вообще, то материалов предостаточно, например:
Как говорится, читать — не перечитать.
Эх, а я думал Вы догадаетесь сами по моему профилю.
И сравнение по скорости запросов чистого SQL с Вашим решением тоже не помешало бы.
PS: сам использую СУБД, нативно поддерживающую ООП (не только для Python), SQL и NoSQL, поэтому и вопросов с ORM не возникает.
Ещё нужно учитывать, что не все возможности Globals API поддерживаются в GlobalsDB: Globals API In Caché
Я пока так и не увидел подтверждения на основе открытых официальных источников ваших слов:
Кулуарная информация меня не интересует.
А специально куда-то писать, чтобы узнать эту информацию, как вы мне советуете, я не собираюсь. И не только поэтому.
Но с внедрением нативной поддержки RFC 6455 необходимость в велосипеде отпала.
Вы всегда пользуетесь только самым-самым и друзья у вас исключительно из списка Forbes?
А насчёт Gartner: так ведь и отчёты по разным темам бывают. Из вашей картинки непонятна тема отчёта.
Странно, что вы не нашли: