В однонаправленной связи «многие ко многим» между Registration
и Item
, где Registration
имеет ISet
. ] и Item
не имеет обратной ссылки на регистрации (это бесполезный способ изучения графа объектов), когда я смотрю на сгенерированный SQL, я вижу
INSERT INTO Registrations_Items (RegistrationId, ItemId) VALUES (@p0, @p1);@p0 = 1 [Type: Int32 (0)], @p1 = 1 [Type: Int32 (0)]
UPDATE Items SET Price = @p0, Name = @p1, [...], ListIndex = @p5, EventId = @p6 WHERE ItemId = @p7
Параметры, переданные в обновление, верны , но в элементе ничего не изменилось, поэтому обновление не требуется.
Сопоставление осуществляется автоматически с этим переопределением для Registration
и без переопределений для Item
. выглядит совершенно правильно Я удалил все соглашения и снова проверил, и поведение сохранилось, так что это не какое-либо из моих соглашений о сопоставлении которые этим занимаются.
mapping.HasManyToMany(e => e.ItemsPurchased).AsSet().Cascade.All().Not.Inverse();
Почему NHibernate делает этот вызов UPDATE
и что я могу сделать, чтобы остановить его? На самом деле ничего не болит, но это говорит о том, что я сделал что-то не так, поэтому я хотел бы выяснить, что.
Редактировать:
Согласно комментарию ниже, я создал модульный тест, который создает Event
(Item
должен принадлежать Event
), добавляет два Item
к это, вытесняет первый из сеанса и очищает сеанс, затем возвращает первый по его идентификатору.
Я заметил что-то странное в строке элементов SELECT ниже (вторая снизу)
INSERT INTO Events (blah blah blah...)
select @@IDENTITY
INSERT INTO Items (Price, Name, StartDate, EndDate, ExternalID, ListIndex, EventId) VALUES (@p0, @p1, @p2, @p3, @p4, @p5, @p6);@p0 = 100.42 [Type: Decimal (0)], @p1 = 'Item 1' [Type: String (0)], @p2 = NULL [Type: DateTime (0)], @p3 = NULL [Type: DateTime (0)], @p4 = '123' [Type: String (0)], @p5 = 0 [Type: Int32 (0)], @p6 = 1 [Type: Int32 (0)]
select @@IDENTITY
SELECT blah blah blah FROM Events event0_ WHERE event0_.EventId=@p0;@p0 = 1 [Type: Int32 (0)]
SELECT itemsforsa0_.EventId as EventId1_, itemsforsa0_.ItemId as ItemId1_, itemsforsa0_.ListIndex as ListIndex1_, itemsforsa0_.ItemId as ItemId3_0_, itemsforsa0_.Price as Price3_0_, itemsforsa0_.Name as Name3_0_, itemsforsa0_.StartDate as StartDate3_0_, itemsforsa0_.EndDate as EndDate3_0_, itemsforsa0_.ExternalID as ExternalID3_0_, itemsforsa0_.ListIndex as ListIndex3_0_, itemsforsa0_.EventId as EventId3_0_ FROM Items itemsforsa0_ WHERE itemsforsa0_.EventId=@p0;@p0 = 1 [Type: Int32 (0)]
UPDATE Items SET Price = @p0, Name = @p1, StartDate = @p2, EndDate = @p3, ExternalID = @p4, ListIndex = @p5, EventId = @p6 WHERE ItemId = @p7;@p0 = 100.42000 [Type: Decimal (0)], @p1 = 'Item 1' [Type: String (0)], @p2 = NULL [Type: DateTime (0)], @p3 = NULL [Type: DateTime (0)], @p4 = '123' [Type: String (0)], @p5 = 0 [Type: Int32 (0)], @p6 = 1 [Type: Int32 (0)], @p7 = 1 [Type: Int32 (0)]
Таблица создана правильно:
create table Items (
ItemId INT IDENTITY NOT NULL,
Price NUMERIC(19,5) not null,
Name NVARCHAR(255) not null,
StartDate DATETIME null,
EndDate DATETIME null,
ExternalID NVARCHAR(255) not null,
ListIndex INT not null,
EventId INT not null,
primary key (ItemId)
)
DateTimes преднамеренно обнуляются, потому что элемент может не нуждаться в привязке к дате (пример что-то, что было бы "ранней регистрацией пташки").