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]>

>  << 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] *On
> Behalf Of *Fabio Maulo
> *Sent:* den 9 oktober 2008 22:12
> *To:* [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]>
>
> 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

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to