Есть ли выигрыш от RecordInsertList

[russ]

Лучше использовать RecordSortedList. RecordInsertList зависит от размера буфера maximum buffer size серверной конфигурации. Перед тем как кол-во записей RecordInsertList превысит максимум, происходит передача записей из RecordInsertList в одном пакете в БД. RecordSortedList не зависит от буфера и передает все записи в одном пакете в момент вызова insertDatabase.
Производительность повышается за счет уменьшения числа обращений АОС к БД: в случае с RecordInsertList будет передано несколько пакетов в зависимости от размера буфера, в случае с RecordSortedList - один пакет. На уровне БД число вызовов insert может оставаться таким же.
Есть также несколько нюансов. Если перекрыт метод insert или таблица содержит memo или container поля, или настроены протоколирование и оповещения, то даже если использованы RecordSortedList и RecordInsertList передача записей БД будет происходит как обычно, по одному. Но есть возможность отключения выполнения insert, протоколирования и оповещений: skipDataMethods, skipDatabaseLog, skipEvents

[fed]

Мне казалось, что RecordInsertList - асинхронный. То есть - в момент отправки заполненного буфера на сервер, он использует какую-то асинхронную форму вызова Native Client, в результате чего приложение не ждет завершения записи пакета. Если у тебя перебор 100000 записей в одной таблице с их трансформацией и перекладкой у другую, то в случае RecordInsertList у тебя система будет ждать только в самом конце (в момент RIL.insertDatabase()) и недолго (поскольку в буффере, допустим, 1500-2000 записей), а в остальных случаях - заполнение очередного буфера будет идти в параллель с записью старого. В случае же использования RecordSortedList, у тебя в конце будет идти ожидание вставки 100000 записей, что в итоге может привести к проигрышу в общем времени исполнения.

DISCLAIMER: Хотя я, вроде бы, где-то слышал про асинхронный режим, я до конца в этом не уверен; Если будете писать подобные операции - попробуйте и RecordInsertList и RecordSortedList и расскажите заинтересованным лицам...

[sukhanchik]

Поддержу fed - сам часто пользуюсь RecordInsertList - у меня тоже сложилось ощущение асинхронности. Но конечно - если кто-то происследует техническую составляющую - будет здорово.

[trud]

Цитата:

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

Лучше использовать RecordSortedList. RecordInsertList зависит от размера буфера maximum buffer size серверной конфигурации. Перед тем как кол-во записей RecordInsertList превысит максимум, происходит передача записей из RecordInsertList в одном пакете в БД. RecordSortedList не зависит от буфера и передает все записи в одном пакете в момент вызова insertDatabase.
Производительность повышается за счет уменьшения числа обращений АОС к БД: в случае с RecordInsertList будет передано несколько пакетов в зависимости от размера буфера, в случае с RecordSortedList - один пакет. На уровне БД число вызовов insert может оставаться таким же.

по моему все же и то и то использует вместо прямого INSERT INTO команду sp_executestatement с заранее подготовленным курсором который состоит из того же INSERT INTO. выигрыш по скорости происходит из-за того, что серверу БД не надо парсить строку SQL. никакой другой магии тут нет

[Logger]

Сомневаюсь что выполнение идет асинхронно.
Если это так то как быть в случае возникновения исключения на вставке ?
Код уже ушел дальше, может даже и транзакция закоммитилась и тут как по волшебству из ниоткуда исключение прилетает о конфликте уникального ключа или еще какая ошибка ?

Это же был бы архитектурный косяк.

[sukhanchik]

Цитата:

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

Сомневаюсь что выполнение идет асинхронно.
Если это так то как быть в случае возникновения исключения на вставке ?
Код уже ушел дальше, может даже и транзакция закоммитилась и тут как по волшебству из ниоткуда исключение прилетает о конфликте уникального ключа или еще какая ошибка ?

Это же был бы архитектурный косяк.

Косяком была бы асинхронная вставка на insert(). А сей класс предназначен для массовой вставки данных. А массовость - она на то и массовость, что имеет определенные допущения в угоду скорости вставки

[Logger]

Цитата:

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

Косяком была бы асинхронная вставка на insert(). А сей класс предназначен для массовой вставки данных. А массовость - она на то и массовость, что имеет определенные допущения в угоду скорости вставки

Не могу с этим согласиться.
Не вижу принципиальной разницы вставки insert() один раз или массово. Даже если бы такое было сделано, должен был бы быть метод позволяющий понять итог этой асинхронной операции. Ну то есть грубо говоря, сессию то гасить (выходить из Аксапты) можно или нет.

[gl00mie]

Использование RecordInsertList предполагает вызов метода insertDatabase() в самом конце для сброса оставшихся в буфере записей, более того, без вызова этого метода никто не гарантирует, что какие-либо записи вообще будут вставлены. Таким образом, этот метод может служить в т.ч. для ожидания завершения предыдущих асинхронных вставок, если предположить, что указанный класс на самом деле выполняет их асинхронно. Что же касается массовых вставок и параллельной обработки, то интересно обратиться к Inside Dynamics AX 2012:

Цитата:

Если среда времени выполнения Microsoft Dynamics AX обнаруживает, что достаточное для формирования пакета количество записей было добавлено в объект RecordInsertList, то записи упаковываются, передаются на сервер базы данных и вставляются в индивидуальном порядке в требуемую таблицу. Данная проверка выполняется при вызове метода add. Когда из прикладной логики вызывается метод insertDatabase, то с использованием того же механизма вставляются оставшиеся записи.
Использование данных классов вместо сценария с использованием оператора while select дает следующее преимущество: выполняется меньшее количество обращений AOS к базе данных, поскольку одновременно отправляются несколько записей. Однако число операторов INSERT на уровне базы данных остается таким же.

Т.е. с одной стороны, явно говорится, что никакого волшебства нет, и записи вставляются по одной, но в СУБД они якобы попадают "пакетом" - возможно, генерится один запрос с кучей insert'ов. С другой стороны, говорится о том, что insertDatabase() использует тот же механизм вставки записей, что и метод add(), а это по идее снижает шансы на то, что add() выполняет вставку асинхронно.

[raz]

Если мне не изменяет мой склероз, то в трешке замечал что RecordInsertList вставлял записи до insertDatabase() (видимо при заполнении буфера), возможно и в новых DAX так же.

[raz]

Цитата:

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

Если мне не изменяет мой склероз, то в трешке замечал что RecordInsertList вставлял записи до insertDatabase() (видимо при заполнении буфера), возможно и в новых DAX так же.

Проверил в DAX 2009, все тоже самое. Прикладываю скриншот и проект, с помощью которого можно проверить.

PS. RecordSortedList работает правильно, записи вставляет по insertDatabase().

[gl00mie]

В приведенном отрывке из Inside Dynamics AX именно об этом и говорится: RecordInsertList может вставлять данные при вызове метода add(), а вызов insertDatabase() лишь сбрасывает в БД записи, оставшиеся в буфере после очередной "пакетной" вставки Поэтому, кроме прочего, работа с RecordInsertList всегда должна быть в транзакции, иначе если в транзакцию вынести только вызов insertDatabase(), то при откате такой транзакции часть созданных записей все равно останется в БД.