http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660doh, strike that - when the type discriminator is not part of the Animals table PK (the case I tend to assume) then ofc there will be only one object with that id in the type hierarchy! http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment56http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment56Sun, 06 Sep 2009 02:37:13 GMTbut how do you know the type without access to the type discriminator ?? http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment55http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment55Sun, 06 Sep 2009 02:34:49 GMTMats, No, the identity map is checked for the type first. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment54http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment54Sat, 05 Sep 2009 22:18:51 GMTAlso...with NH's current approach, wouldn't you need an additional round-trip to the database (when the proxy is accessed, fetching the type discriminator) in order to determine if the object is already in the identity map (In which case, is the rest of the data loaded redundantly)? Or can you find the object in the identity map without knowing the type discriminator somehow ? /Mats http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment53http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment53Sat, 05 Sep 2009 20:23:35 GMTI would argue that it would be preferable to 1) have the AnimalType type discriminator field be part of the primary key of the Animals table 2) Also (therefore) have an AnimalType field in the AnimalLover table, which is also part of the foreign key pointing to the Animals table. When you have this setup, the problem goes away, since you can know when loading the proxy what the correct type is. When the type discriminator field is absent from the AnimalLover table, I'd argue that the proper behavior is to join in the type discriminator from the Animals table so that you have the information when you need it - even if lazy loading had been turned on for the AnimalLover.Animal reference property (the rest of the Animals columns should then not be loaded), since this is what has to be done for correctness. /Mats http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment52http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment52Sat, 05 Sep 2009 20:16:26 GMTWould it really be that hard to give people "a choice" about the proxying behavior (admittedly an advanced choice)? Why do you want to keep things "pure"? I understand both decisions to make the proxying behave like it does. In commercial software it's either a strategic design choice or what the customer asks for. In opensource I think it's purely a strategic choice. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment51http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment51Sat, 05 Sep 2009 13:06:45 GMTYes I agree that there are two approaches and if you pick one you have the advantages of one but the disadvantages as well. Your advantage, that accessing the property in comparisons for example doesn't load the entity is good for some situations (as it avoids unnecessary queries perhaps), but it can be a burden as well in others (as roger pointed out in the other thread). So 'it depends on the ORM used' if this fails or not. Which is better than 'it is true for any orm' ;) http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment50http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment50Sat, 05 Sep 2009 10:08:09 GMTFrans, The difference is why you are generating the proxy. NH is generating the proxy on hydration of the AnimalLover, you seems to generate it on accessing the Animal property. There are different data sets that you have at each point. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment49http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment49Sat, 05 Sep 2009 09:52:04 GMTFrans, Okay, I see how you do it. I don't like this approach, because of its data focus, but I agree that it is a choice that you can make. With NH, just accessing the property will not cause a load (see the discussion on the advantages that it gives NH in the previous post comments). One major implication of that is that we can support a non proxied root classes. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment48http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment48Sat, 05 Sep 2009 09:50:58 GMT> I am sorry, I don't get the last comment. Lazy loading _is_ done here. then I don't see why you can't return the right typed object. The reason for this is that the discriminator value is in the data you fetch from the DB, so the session can create the right instance based on the discriminator value. So 'is' will work (IMHO, but I'm not an expert on NH's proxy system). http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment47http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment47Sat, 05 Sep 2009 09:48:09 GMT>What SQL would be generated and at which line? at this line: var animalLover = GetById(1); you'll get the SELECT ... FROM AnimalLover WHERE ID=@id at this line: Console.WriteLine(animalLover.Animal.Id); you'll get the SELECT ... FROM Animal WHERE ID = @id -- @id is the 'Animal' value from the Animal lover. This is because you touch the lazy loaded property. This is a decision in the O/R mapper what will happen: some will indeed trigger lazy loading, load the related entity and be done with it, but ones which don't support FK fields, have the FK field 'AnimalLover.Animal' stored in the animalLover.Animal.Id value, and thus have a problem which isn't really solveable. That doesn't mean it's true for _all_ o/r mappers, just the ones which store FK field values that way. At the line: Console.WriteLine(animalLover.Animal.Name); you don't get any sql as the instance was already loaded. It's a decision for the ORM to support FK fields or not, and some will say it's stupid to support them at the entity level, while others say it's wise to do so. 7 years ago I made the decision to support them as it makes things much easier than when you ignore them. That turned out to be a good decision as it solves a lot of problems like the ones you presented here. It also makes things less 'OO', as an FK field is simply a copy of the PK of the related entity, so storing that twice sounds smelly. I guess, it depends on how you want to work with the entity instances (data) in memory when they're stored inside entity class instances (objects): not supporting FK field values (and thus use the pk of the related entity) makes things more OO, but gives problems, supporting them makes things less OO but solves problems. (and gives some others, like you have to actively dereference entities when fk field values change, something you don't have to do) In the end, I think (but that's a personal perspective I think) it depends on whether you want to abstract away the relational aspect of a database or not. I definitely don't want to do that, as it has advantages as well, and others think differently and think it gets in the way. Both have good/bad points, so it's up to the user whether fk field values belong to the entity they're in or not. Personally, I think they belong to the entity, as they're the only evidence in an entity it is related to another entity, but opinions on that differ :) http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment46http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment46Sat, 05 Sep 2009 09:44:54 GMTFrans, I am sorry, I don't get the last comment. Lazy loading _is_ done here. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment45http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment45Sat, 05 Sep 2009 09:37:18 GMTI have to add that the article assumes that lazy loading is done, but that's not really done, is it? You return an instance from the property which doesn't contain data. But isn't that odd, as accessing the property will trigger lazy loading, go to the db, load the related instance and return the instance with the right type (at least that would be the proper action). http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment44http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment44Sat, 05 Sep 2009 09:33:48 GMTFrans, Given the class: create table AnimalLovers ( Id, Name, AnimalId ) create table Animals (Id, Name, Type ) And the following code: var animalLover = GetById(1); Console.WriteLine(animalLover.Animal.Id); Console.WriteLine(animalLover.Animal.Name); What SQL would be generated and at which line? http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment43http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment43Sat, 05 Sep 2009 09:32:19 GMTYour remark about 'it's not specific for any O/RM' is wrong, ours does this properly (it returns the proper entity with the right type, not a proxy). The only o/r mappers which do this wrong are the ones which use proxies for Lazy loading and/or return proxies. It's easy to solve really: just call the polymorphic fetch method you already have for fetching polymorphic single entities (e.g. you want animal with ID 3, if it's a cat you return a cat instance etc.) and you're done. THis isn't difficult, actually it's re-using code that's already there. The only change you have to make is that the animallover proxy knows this. But then again, I'm not a NH expert. However saying this is a thing that all o/r mappers suffer from is misleading, some do the proper thing. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment42http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment42Sat, 05 Sep 2009 09:29:16 GMTP, NHibernate doesn't support just a single use case, and there are reasons to want non lazy entities. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment41http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment41Thu, 03 Sep 2009 21:21:24 GMTRight...but so what? Lazy loading is the default behavior in most ORMs references. Since AnimalLover is returned from the persistence layer it's easy to return a proxy that overrides the Animal property and loads it as needed. This just doesn't seem like that complicated a problem. The only time it becomes an issue is when you're querying a bunch of AnimalLovers at the same time that each love a different kind of animal. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment40http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment40Thu, 03 Sep 2009 21:16:47 GMTP, That doesn't works if the AnimalLover itself is non lazy, though. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment39http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment39Thu, 03 Sep 2009 20:40:20 GMT"Look at the generated SQL, we want to avoid hitting the _other_ table at load time for the animal lover instance. This is a very important optimization because otherwise you very quickly have 17 ways joins." You don't have to look at the Animal table at all until the Animal property itself is accessed. The AnimalLover class loads as a proxy. The Animal property is lazy loaded so that the first time it's accessed it hits the table. It already needs to do to support lazy loading so there's no extra hits on the database, yet it actually performs as developers expect. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment38http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment38Thu, 03 Sep 2009 19:57:22 GMTRight and wrong isn't easy here, because: From an OO perspective, "var isDog = animalLover.Animal is Dog;" is not so good, there are better alternatives like visitors etc. Or you could even do "var isDog = animalLover.Animal.AnimalKind == AnimalKinds.Dog;". Since relying on casting isn't good, there is no need to support it at the cost of performance. (And yes you can do lazy=false in NH) But from a new user perspective with maybe less OO knowledge, "var isDog = animalLover.Animal is Dog;" is perfectly valid, and he expects it to work. I can understand if with a commercial ORM, users want this to work and the ORM vendor wants to please its customers, and so this gets implemented. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment37http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment37Thu, 03 Sep 2009 18:52:55 GMTJosh, Only if it was on the AnimalLover table, otherwise you still don't have enough info to tell when you select just from AnimalLovers http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment36http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment36Thu, 03 Sep 2009 18:40:31 GMTIf you had mappings for all the subclasses, with the animaltype field being the discriminator value to distinguish between the types - would it not return a proxy of a Cat, Dog, etc instead? http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment35http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment35Thu, 03 Sep 2009 17:00:29 GMTHi, We came accros the same issue in our system and came up with a way of solving the issue. Not sure if there is some underlying problem with the solution that we haven't spotted but here goes: All our domain objects inherit from an object called BaseDomainObject. BaseDomainObject has a property on it called UnProxied and all this does is returns the current object: public virtual BaseDomainObject UnProxied { get { return this; } } So for any proxied domain object you can just access the UnProxied property and be given the actual object. Would there be any NHibernate issues with this approach? http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment34http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment34Thu, 03 Sep 2009 15:06:38 GMTSebastian, NH doesn't do eager getter, if you want that, use the any option http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment33http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment33Thu, 03 Sep 2009 13:36:23 GMTMarco, Yes, that is one option http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment32http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment32Thu, 03 Sep 2009 13:34:56 GMT> It isn't the wrong type, it is the type specified in the mapping and matching the DB configuration. Oren, you know, you're right! That's just one more "feature" :) > Also, please be aware that based on our previous discussion I am aware that this can be a long thread, and I am not going to invest any time in this Me too ;) http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment31http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment31Thu, 03 Sep 2009 13:29:59 GMT> It is interesting whether it is possible to do unsafe memory-patching to achieve this This is definitely impossible: - If you already got a reference, its type can be cached somewhere. And you don't know where. - Moreover, likely there is simply no free space after the object`s area in RAM. If you aware how .NET distributes the memory & how mem. compactions are actually running, it's clear the only case when additional space is located after your object is case when there is some "dead" object. But only GC will be able to recognize this. http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment30http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment30Thu, 03 Sep 2009 13:28:15 GMTAyende, I see, you mean that it should use that SQL query ONLY. Marco, I have used this practise a lot in real applications and it's not always as simple as that. For example a reference to a ghost object may not exist: var proxy = session.get(missingID); or many-to-one references that has since been removed etc. There is added value to it but there's also a useful middle ground between lazy false and lazy true. The premise here is that I need to retrieve the Animal property without actually doing anything with it. Most of the time that I visit the Animal property I will want to do something with it. Then it's ok for me to load it during the "property get". The exception is when I have things like lover.Animal.ID or lover.Animal.Ancestor.Ancestor.GetDNA(); As for reading the ID field without loading the entity, I tend do that using session.GetIdentifier(entity) in my architectural pattern or by mapping the relationship as a Dictionary where the ID is the key. If I'm traversing multiple nodes down a graph, for me, this usually means I have a projection coming so I'd use a query instead. For the exception where I do need lazy graph building I'd happily opt-in, in my mapping. So I'd love to see an option to map many-to-one properties as "eager getter" or something. Sorry for hogging the thread. :) http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment29http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment29Thu, 03 Sep 2009 13:24:45 GMTanimal is a foreign key, it's the DB that checks about data corruption. about your question with that option you have 2 column, 1 with the FK and 1 with the .NET type? (i'm not sure to have understand) http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment28http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment28Thu, 03 Sep 2009 13:09:34 GMTRoger, Of course I don't take offence :-) With NHibernate, you can make use of the exact same method by defining the association as [any/] Any association encode both the type of the association and the association id in the parent table, so you can get the info (and the appropriate type) in a single call. The problem is that [any/] relations are pretty rare in the DB world http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment27http://ayende.com/4168/answer-the-lazy-loaded-inheritance-many-to-one-association-or-m-conundrum#comment27Thu, 03 Sep 2009 12:58:54 GMT