Цитата:
Сообщение от
mazzy
Если у вас всегда один АОС,
Если у вас никогда не используется кэширование таблиц,
Если у вас никогда не будет виртуальных компаний,
Если у вас никогда не будет доменов и т.п.
То подумать на тему "переопределить" можно.
АОСов несколько,
кеширование (если речь идет про свойство CacheLookup у таблиц) очевидно применяется где-то, например в стандартном функционале, и его отключать не хочется
виртуальная компания есть (vrt)
домены есть
Цитата:
Сообщение от
mazzy
Не нужно так делать. Ни в коем случае.
там зарыто столько скелетов... прежде всего с кэшированием таблиц и работой в кластере АОСов.
я уверен, что никакой "более гибкий" не может перекрыть затрат на борьбу со скелетами.
...
Если хоть что-то и перечисленного есть - дешевле будет перейти на следующую версию Аксапты.
Хм, понятно что все непросто.
Ситуация такая что на достаточно большой базе (1,7 Тб, 4.5 лет) приближается нулевое значение recId. Поэтому ищется как раз решение подешевле. Пока выбирается между: 1) дефрагментацией, 2) реализацией механизма заполнения дырок, хотя очевидно также потребуется 3) чистка старых InventTrans (сильно не тривиальная задача), ну или 4) переезд в новую базу с остатками. Пока реализация механизма заполнения дырок видится самой легкой из вышеперечисленного. Вариант перехода на следующую версию Ax пока не рассматривается.
Но встает вопрос про некоторую "ассинхронность" выделения блока новых recId между AOS и SQL. Так триггер на SQL отрабатывая еще не знает какой в будущем непрерывный блок идентификаторов попросит у него AOS, и поэтому алогритмически не может точно выбрать самую подходящую дырку. Остается только реализовывать какие-то эмпирические подходы, ну или в случае попыток выделения чрезмерных блоков обрывать такие попытки через reaiseerror в триггере. При этом Ах-код очевидно может свалиться в самых произвольных местах, и тут остается верить что код достаточно покрыт транзакциями, и/или быть готовым к неожиданностям.
Вот поэтому хотелось бы как-то в триггере (или в другом месте - переопределении класса SystemSequence?) в момент резервирования очередного непрерывного блока сразу выдавать ему самую подходящую по размерам дырку.