nhibernate sesion On Tue, Dec 16, 2008 at 11:20 AM, epitka <[email protected]> wrote:
> > you just said session, so I am wondering what you thought. > > On Dec 16, 10:12 am, "Ayende Rahien" <[email protected]> wrote: > > On what exactly? > > > > On Tue, Dec 16, 2008 at 11:04 AM, epitka <[email protected]> wrote: > > > > > Ayende, can you expand on this? > > > > > On Dec 16, 8:45 am, "Ayende Rahien" <[email protected]> wrote: > > > > On Tue, Dec 16, 2008 at 5:29 AM, Symon Rottem <[email protected]> > > > wrote: > > > > > There are a couple of problems with this approach - it's pretty > good, > > > but I > > > > > it's still got a couple of holes. > > > > > > > There are a couple of issues: > > > > > > > 1. The cast in the equals method will not necessarily result in > the > > > type > > > > > you're expecting: > > > > > > > T other = obj as T; > > > > > > > If the current instance is a DomesticCat and the passed instance is > a > > > Cat > > > > > proxy that, in fact, represents a DomesticCat instance then the > cast > > > would > > > > > fail and return null because the Cat proxy cannot be cast to > > > DomesticCat. > > > > > This could be worked around using the > NHibernateUtils.GetClass(entity) > > > > > method, but that might cause performance issues since the DB would > need > > > to > > > > > be hit for proxies... > > > > > > > This doesn't happen in practice. Because it is Cat that inherit > from > > > EAHCP. > > > > > > > 2. This approach will still break if you have a transient entity > that > > > you > > > > > persist then evict from the Session thereby making it disconnected > then > > > > > compare it with another loaded copy of same entity; the loaded > entity > > > and > > > > > the disconnected entity will be seen as equal but will have > different > > > > > hashcodes breaking the contract which indicates that if equals() > > > returns > > > > > true then hashcode comparison should also return true. > > > > > > > This approach assume that you are using an entity in the context of > a > > > > > > session. If you try to mix things, it is on your head to make sure > > > > everything works. > > > > > > > Certainly the approach will work for the majority of > circumstances, > > > but > > > > > it's probably worth being aware of the pitfalls just in case you > fall > > > into > > > > > them. :) > > > > > > > Personally I've worked around the problem by making a base class > for my > > > > > entities that has a read only "lifetime id" property that's > allocated a > > > GUID > > > > > value at instantiation and is used for equality and hashcode > > > comparisons. > > > > > Note that this property is *not* used as the identity map - my > entities > > > > > still have an Id property for that. The "lifetime id" property is > > > persisted > > > > > and mapped using field access so the read only property can be set > when > > > a > > > > > persisted entity is loaded. > > > > > > > In effect, the GUID is generated when the transient instance is > > > > > instantiated and is then persisted with the object; at any point > that > > > the > > > > > persistent entity is reloaded the value is reloaded with it. If > the > > > entity > > > > > is evicted from the session or the session is closed making it a > > > > > disconnected entity the lifetime id doesn't change. If the entity > is > > > > > deleted and made transient it still remains the same. You could > even > > > > > re-persist it. > > > > > > > Of course, the drawback is that every entity row must now store an > > > > > additional GUID, however it's not necessary to have an index on > this > > > column > > > > > as it will never be searched, so it's not *too* expensive. You > might > > > want > > > > > to make it unique, however, but I don't this it's essential as the > > > > > likelyhood of having two conflicting GUIDs in memory at the same > time > > > seems > > > > > rather low. > > > > > > > There may be a better way of handling this, but I haven't found it. > :) > > > > > > > Cheers, > > > > > > > Symon. > > > > > > > On Tue, Dec 16, 2008 at 5:33 AM, Ayende Rahien <[email protected]> > > > wrote: > > > > > > >> > http://ayende.com/Blog/archive/2007/06/05/Generic-Entity-Equality.aspx > > > > > > >> On Mon, Dec 15, 2008 at 11:32 PM, Tim Barcz <[email protected]> > > > wrote: > > > > > > >>> I am reading through a book on NHibernate (NHIbernate in Action, > > > Manning) > > > > >>> and when talking about comparing entity values based on database > > > identifier > > > > >>> (which is what EntityBase does) it strongly discourages equality > > > based on > > > > >>> database Id's: > > > > > > >>> Unfortunately, this solution has one huge problem: NHibernate > doesn't > > > > >>>> assign identifier values until an > > > > >>>> entity is saved. So, if the object is added to an ISet before > being > > > > >>>> saved, its hash code changes while it's > > > > >>>> contained by the ISet, contrary to the contract defined by this > > > > >>>> collection. In particular, this problem makes > > > > >>>> cascade save (discussed later in this chapter) useless for sets. > We > > > > >>>> strongly discourage this solution (database > > > > >>>> identifier equality). > > > > > > >>> Generally DDD looks at an Entity's unique ID for determining > > > equality. > > > > >>> However I'm a bit concerned at the strong warning from the > NHibernate > > > camp > > > > >>> about this type of equality comparison. > > > > > > >>> What's the thought on this? I'd be interested in hearing > arguments > > > on > > > > >>> either side. > > > > > > >>> Tim > > > > > > > -- > > > > > Symon Rottem > > > > >http://blog.symbiotic-development.com > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
