Миф об уникальности RecId?

[Gustav]

Цитата:

Сообщение от Alenka

Наконец-то нашлось время на испытание, проверку и тестирование идеи с триггером. Выяснилось, что, к сожалению, сама идея заполнения дыр, оставляя в запасе 25 номеров, "не дружит" с insert_recordset. При использовании insert_redordset значение nextVal в SystemSequence передвигается сразу на количество вставляемых записей. Поэтому необходимо держать в запасе в текущей дыре с неиспользованными RecId не 25 номеров, а неограниченное количество, что естественно невозможно.
2 Gustav: Этот случай был просто не учтен Вами или есть какое-то решение?

Тэк-с... Давайте по порядку. Отдельно специально такой случай не изучался и к сожалению не могу его быстро проверить. Но есть мысли. Полагаю, что этот случай практически относится к моим опасениям с размером кэша, отличным от 25:

Цитата:

Сообщение от Gustav

2. У таблицы SystemSequence в Ax 3.0 имеется метод setCacheSize, позволяющий установить размер кэша иным, нежели 25. Перед использованием триггера рекомендуется проверить код приложения Аксапты на присутствие вызовов этого метода (у меня не было ни одного). При необходимости можно увеличить minDelta в триггере до значения максимального параметра этих вызовов, либо (более муторно) в триггере предусмотреть генерирование ошибки (исключения) при попытке Аксапты сделать шаг больше, чем 25.

Ключевая подстрока - "при попытке Аксапты сделать шаг больше, чем 25". Перед изменением nextVal в триггере вы контролируете и старое (:Old.NextVal), и новое (:New.NextVal) значения. И соответственно можете вычислить дельту и направить алгоритм в дырку соответствующего размера. Для быстрой реакции разумно будет добавить соответствующее поле HoleSize в таблицу RECIDHOLES. Естественно, придется должным образом модифицировать алгоритм триггера.

Логично? Или я выдаю желаемое за действительное? Еще раз отмечу, что в данный момент могу рассуждать только теоретически.

[Alenka]

Нет, такой анализ не поможет, т.к. проанализировать-то можно, а исправить ничего уже будет нельзя, т.к. вставляемым записям будут присваиваться RecId, начиная со старого значения. Т.е. надо было при предыдущем смещении nextVal "предусмотреть" возможность вставки с помощью insert_recordset.

[Alexius]

Цитата:

Сообщение от Alenka

... "предусмотреть" возможность вставки с помощью insert_recordset.

Боюсь это придется делать в АХ, т.е. "прошерстить" код и делать уже там перенаправление на самую большую дырку

Можно попробовать забить на эту проблему, ну не пройдет с первого раза транзакция, так пройдет со второго
Потом в АХ найдется немного мест, которые требуют уникальности RecId в разрезе нескольких таблиц, т.ч. шансы на удачный исход дополнительно повышаются

[Alexius]

Цитата:

Сообщение от Gustav

Перед изменением nextVal в триггере вы контролируете и старое (:Old.NextVal), и новое (:New.NextVal) значения.

Беда в том, что (:Old.NextVal) и является первым выделенным RecId для текущей вставки, а (:New.NextVal) очередной RecId уже для следующей вставки и изменить можно только его.

[Gustav]

Цитата:

Сообщение от Alenka

Нет, такой анализ не поможет, т.к. проанализировать-то можно, а исправить ничего уже будет нельзя, т.к. вставляемым записям будут присваиваться RecId, начиная со старого значения. Т.е. надо было при предыдущем смещении nextVal "предусмотреть" возможность вставки с помощью insert_recordset.

Цитата:

Сообщение от Alexius

Беда в том, что (:Old.NextVal) и является первым выделенным RecId для текущей вставки, а (:New.NextVal) очередной RecId уже для следующей вставки и изменить можно только его.

Да, да! Не прав я, коллеги, признаю!

insert_recordset, желающий вставить 100 записей (вместо 25), вероятно, возьмет старый nextVal и прибавит к нему 100 и попытается сохранить в SystemSequence для последующих запросов.

Что можем мы в этой ситуации? Можем увидеть, что собирается быть выполненным шаг больше 25, а также проверить существует ли свободное пространство в текущей дыре для выполнения этого шага. Если оно есть, то всё в порядке. Если его нет, то выбирать следующую подходящую дыру бесполезно, так как наш insert_recordset уже запомнил для себя 100 последовательных номеров - надо генерить ошибку (исключение). При этом можно, конечно, уже иметь на примете следующую подходящую дыру.

В общем, дальнейший успех зависит от того, сможем ли мы хорошо обработать это исключение. Тогда текущая попытка увеличения nextVal будет как бы холостым шагом, а следующая после обработки исключения попытка выделения 100 номеров будет успешной. Блин, должна быть!