У меня есть 2 класса, в которых классы многих-многих сопоставлены друг с другом.
Вот упрощенное отображение двух моих классов:
Транспортное средство:
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<class xmlns="urn:nhibernate-mapping-2.2" name="EMTRAC.Devices.Device, EMTRAC_v3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" table="`Device`">
<id name="PK" type="System.Int64, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="PK" />
<generator class="identity" />
</id>
<version name="LastModifiedOn" column="LastModifiedOn" type="timestamp" access="field.pascalcase-underscore" />
<joined-subclass name="EMTRAC.Vehicles.Vehicle, EMTRAC_v3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
<key>
<column name="Device_id" />
</key>
<component name="Zones" access="property">
<bag name="_list" cascade="save-update" access="field" table="VehicleZones" inverse="true">
<key>
<column name="veh_id" not-null="true"/>
</key>
<many-to-many class="EMTRAC.Zones.Zone, EMTRAC_v3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</bag>
</component>
<property name="ID" type="System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="ID" />
</property>
</class>
</hibernate-mapping>
Зона:
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<class xmlns="urn:nhibernate-mapping-2.2" name="EMTRAC.Zones.Zone, EMTRAC_v3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" table="`Zone`">
<id name="ID" type="System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="PK"/>
<generator class="identity" />
</id>
<version name="LastModifiedOn" column="LastModifiedOn" type="timestamp" access="field.pascalcase-underscore" />
<property name="ID" type="System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<column name="ID" />
</property>
<component name="Vehicles" access="property">
<bag name="_list" cascade="save-update" access="field" table="VehicleZones">
<key>
<column name="veh_id" not-null="true"/>
</key>
<many-to-many class="EMTRAC.Vehicles.Vehicle, EMTRAC_v3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</bag>
</component>
</class>
</hibernate-mapping>
В моей программе у меня 9600 зон и 5000 транспортных средств для стресс-теста системы.Каждая зона в настоящее время сопоставлена с каждым транспортным средством, и наоборот, чтобы имитировать «худший» сценарий в реальном мире.
Мне нужно сохранить эти данные стресс-теста в базе данных, и у меня возникло несколько проблем, так кактаблица, которая отображает эти два списка, будет содержать 48 миллионов строк к тому времени, когда это будет сказано и сделано.В реальном мире вероятность сохранения всех предметов за один раз будет очень минимальной, но все же это произойдет.Поэтому мне нужно быть уверенным, что можно будет сохранить столько элементов в любой момент времени, хотя я знаю, что это займет значительное время.
Я знаю, что для пакетной обработкирекомендуется сеанс без сохранения состояния.Однако я прочитал, что сеансы без сохранения состояния игнорируют каскадные обновления, наследование и коллекции в целом.Сохранение элементов в сеансе без сохранения состояния в настоящее время невозможно, так как я получаю исключения переполнения стека во время вызова фиксации.
У меня такой вопрос.Если я сначала сохраню все Зоны и Транспортные средства, то объекты сохранятся в базе данных.Можно ли сохранить списки с помощью сеанса без сохранения состояния, и если да, то как мне это сделать?Если нет, есть ли другие рекомендации?Все, что я пытался использовать StatelessSession, не приводило к исключению persister for Collection.
EDIT Я отслеживал сохранение этих объектов с помощью обычного сеанса.Если я разбиваю сохранения на сохранение каждые 100 в другом сеансе и транзакции, они сохраняют все остальные свойства зоны каждый раз, когда я вызываю SaveOrUpdate на транспортном средстве.
Есть ли способ заставить его сохранитьСписок, а не трогать ли саму машину или зону объекты?Похоже, это то, что мне нужно, чтобы эта последняя часть работала.