Есть велосипедная система версионирования, пишущая сериализованные объекты в РС, все работало, пока не попался уж больно большой объект.

    Запись = Новый ЗаписьXML;
    Запись.УстановитьСтроку();
    СериализаторXDTO.ЗаписатьXML(Запись, Источник);
////////////// тут падает >
    XML = Запись.Закрыть();
////////////// < тут падает
    
    Запись = РегистрыСведений.ИсторияИзмененийXML_ПодчиненныеРегистры.СоздатьМенеджерЗаписи();
    Запись.Период = ТекущаяДата();
    Запись.СсылкаНаРегистратор = Источник.Отбор.Регистратор.Значение;
    Запись.Метаданные = ПолноеИмяМетаданных;
    Запись.Действие = ?(Источник.Количество() = 0, Перечисления.ИсторияОбъектовДействия.Удаление, Перечисления.ИсторияОбъектовДействия.Изменение);
    Запись.УникальныйИдентификатор = Новый УникальныйИдентификатор;
    Запись.ХранилищеXML = Новый ХранилищеЗначения(XML, Новый СжатиеДанных(9));
    Запись.АвторИзменений = ПараметрыСеанса.Сотрудник;
    Запись.ИмяКомпьютера = ИмяКомпьютера();
    Запись.ИнформационнаяБаза = ПараметрыСеанса.ИБЭтогоУзла;
    Запись.Записать();

как бы обойти?

кстати, вылетает на 32битном клиенте, так как куча файловых баз. на 64битном сервере вроде ОК.

в смысле, перевесит всех на клиент-сервер - не предлагать :)

на сервере выгружай. В чём проблема?
или руками сериализацию пиши

(3)->(2)

руками сериализация кушает памяти намного больше, не?

и времени занимает сильно больше

(0) Никак. У тебя в области памяти процесса нет непрерывного свободного блока на 100500 мегабайт.
Пеши в файл.

(7) а потом что? надо ж в РС сохранить...

(0)вам не нужны версии настолько больших объектов

(8)

ДвоичныеДанные=Новый ДвоичныеДанные(КаталогФайловXML+НовСтр.ИмяФайла);

НовСтр.СжатыйТекст = Новый ХранилищеЗначения(ДвоичныеДанные,Новый СжатиеДанных(9));

записьfastinfoset походу сильно меньше памяти жрет

(11) Только это будет двоичный формат

(11) Который, к тому же, недоступен на Тонком клиенте.

Все это я узнал, когда занимался оптимизацией передачи данных с сервера на клиент.

(11)+ кому интересно: http://wstaw.org/m/2015/01/27/0.png

Объясните зачем раздувать рабочую базу за счет хранения разных версий? Или у Вас это документооборот?

(15) чтобы можно было вернуться к предыдущему состоянию объекта, а также надавать по шапке тому, кто поменял что не надо.

(16) это понятно, а зачем это хранить в рабочей базе? почему не отдельно от базы актуальной?

(17) например из-за того, что РИБ, и история должна как-то прилететь в центр, откуда оно, например, улетит в архивную базу...

(18) офигеть еще и РИБ ;)

но смысл понятен, хотя сделал бы отдельный лисапед для логирования действий/состояний объектов

тупо перед/после записи объектов на диск/в отдельную базу бы их писал )) а не в рабочую базу чтоб не пухла, но тут от объемов конечно

можно и в рабочую и периодически чистить с выгрузкой

(15) Чем мешает раздувание базы?

(20) да ничем собственно, кроме некоторых (легких) тормозов со временем и/или необходимостью обновлять сервак (диски для рейд немного кусаются)

(20) да ничем оно не мешает. сейчас давайте подумаем над тем, что лучше в данном контексте: XML через временный файл или FastInfoSet?

(22) двоичные данные (сжатые) лучше, imho

(22) FastInfoSet через временный файл, ибо и с FastInfoSet -ом со временем напорешься.

Хотяяя, если время создания не критично - лучше XML, чтобы можно было разобрать руками, еслифчо.

(22)(24) гыгы

а раз один фиг пишем из базы на диск во временный файл, то зачем потом тратить время на чтение назад в базу?

не лучше ли отдельное что то будет читать и грузить к себе эти файлы ))

да, через файл выгружается подольше, но зато память не растет ВООБЩЕ

(20) Ограничением на размер таблицы в файловой базе? :)

(28) одна запись    
Запись.ХранилищеXML = Новый ХранилищеЗначения(XML, Новый СжатиеДанных(9));
как правило занимает намного меньше места, чем соответствующий её набор данных

вот еще вопрос: для вынимания из транзакции хотелось сделать передачей XML в фоновое задание. с файлом - можно передавать имя файла, что даже проще. Но тогда остается вопрос с тем, как отловить отвалившуюся транзакцию, например из-за срабатывания Отказ = истина в ОбработкаПроведения или отката по блокировкам*

?

(30) щта?

(30) дык вот не пофиг что не провелось, один фиг пишем же что записалось, ну будут дубли не измененных записей

(30) пиши в той же транзакции подпиской в отдельную очередь (рс, справочник) только ссылки, а фоновым разгребай ссылки и сериализуй. попадешь на race condition - приходи еще :)

Понял.

Я бы в ОбработкеПроведения документа писал бы в служебный регистр вида

Измерения:
ДокументСсылка,
УжеЗаархивировано

Все. Легко и просто.

Фоновые задания ходили бы по этому регистру, вытаскивали незаархивированные и архивировали.

При этом ставя исключительную блокировку на весь диапазон ДокументСсылка.

1 проведение выполняется без всей этой архивной фигни.
но есть вариант пропустить версию.

Поэтому либо пропустить эту версию, либо ждать, пока документ будет заархивирован фоновыми.

(36) + при повторном проведении

Если же будет откат транзакции на 1 проведении - не будет записи в регистре и все ок.

Кста а пишем то значения новые (сразу после записи. в т.ч. для новых объектов, старые один раз при внедрении фишки) или старые до записи?

При архивировании база не читается.
(36) у меня сейчас сохраняется всё - документы, справочники, движения, независимые регистры.

потом дедупликация, отчеты о сравнении всякие, кнопка отката к предыдущему состоянию и т.п.

(29) Соответствующий ей набор данных как правило не лежит в одной таблице.