Yes, the clone has a new collection instance of type List<T> (while the persisted's collection is of type PersistentGenericBag<T>). The same would (normally I guess?) be true if trying to merge an object populated from a DTO. Is this not supposed to work when trying to merge?
________________________________ Från: [email protected] [EMAIL PROTECTED] för Fabio Maulo [EMAIL PROTECTED] Skickat: den 9 oktober 2008 23:42 Till: [email protected] Ämne: [nhusers] Re: Session.Merge() -> session dirty >From the first quick look you are changing the list of children in a persisted >object. BTW I will take a look to give you an answer. 2008/10/9 Roger Kratz <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> Totally understand if you don't understand. Hopefully my c# is easier to understand :) The JIRA is here (with test) http://jira.nhibernate.org/browse/NH-1519 Thanks for your time /Roger From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Fabio Maulo Sent: den 9 oktober 2008 23:14 To: [email protected]<mailto:[email protected]> Subject: [nhusers] Re: Session.Merge() -> session dirty I continue without understand so please create a NUnit-test-case and THEN create a JIRA with the test attached. Thanks. 2008/10/9 Roger Kratz <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> << it depend on what you are doing in ent.DeepCloneOfAggregate() and in "...">> I meant ISession firstUow=[…]; Entity ent= LoadAnEntityUsingfirstUow(); Entity entClone =ent.DeepCloneOfAggregate();… ISession s2=[…]; session.Lock(ent, LockMode.None); session.Merge(entClone); Assert.IsFalse(session.IsDirty()); << why use session.Lock when the Merge reattach the entity to the new session ?>> We want to avoid the round trip to the database and instead "give" the ISession the original object. In "real life" we don't have one entity, but many. << why use a clone when Merge return an updated version of your entity without touch the original one ? >> In our desktop client we sometimes need to load data, clone this data and work with this cloned data. When later persist this, it's handy to use ISession.Merge to find out the data diff between the original data and our changed cloned data. This is an issue for our fat desktop application. Our use case is as follows.. 1 Load much data (in a short living uow) 2 Clone this data 3. Work with this cloned data 4. Persist the change (in a new uow) In 4, I was hoping to be able to tell the new ISession what "1" was by using session.lock on the data, then merge this with the cloned data and then let nhibernate flush the changes. This would work perfectly fine if we weren't using optimistic lock (non modified data won't be persisted). Now when we do – even non changed entities will be persisted. If you say "it should work", I send the unit test to the JIRA exposing this bug (?). /Roger From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Fabio Maulo Sent: den 9 oktober 2008 22:12 To: [email protected]<mailto:[email protected]> Subject: [nhusers] Re: Session.Merge() -> session dirty it depend on what you are doing in ent.DeepCloneOfAggregate() and in "..." I don't understand various things... 1) why use session.Lock when the Merge reattach the entity to the new session ? 2) why use a clone when Merge return an updated version of your entity without touch the original one ? doc of Merge /// Copy the state of the given object onto the persistent object with the same /// identifier. If there is no persistent instance currently associated with /// the session, it will be loaded. Return the persistent instance. If the /// given instance is unsaved, save a copy of and return it as a newly persistent /// instance. The given instance does not become associated with the session. /// This operation cascades to associated instances if the association is mapped /// with cascade="merge". 2008/10/9 Roger Kratz <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> Hi Is this suppose to work? Entity ent=[…]; Entity entClone =ent.DeepCloneOfAggregate(); … session.Lock(ent, LockMode.None); session.Merge(entClone); <--has not been changed Assert.IsFalse(session.IsDirty()); It works if "ent" does not have any collection. If it has, the session becomes dirty. If "ent" is not versioned/has optimistic lock, nothing will be persisted. However, because entity is considered dirty, if flushing this session, "ent" will be persisted to the db with a new version number even though no data has been changed. Is this by design or is this a bug that I should JIRA this? /Roger -- Fabio Maulo -- Fabio Maulo -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
