Feels like the right solution is to have the parent assembly contain two mapped address classes.
BaseAddress which is abstract and HomeAddress which subclasses is. Put the discriminator value of 'home_address' in the mapping of HomeAddress and you're done. Other assemblies can subclass BaseAddress or HomeAddress, pick their discriminator value and you're good to go. Jon From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Tuna Toksöz Sent: Friday, September 26, 2008 1:55 PM To: [email protected] Subject: [nhusers] Re: Discriminator bug What if the parent is in another assembly(so is its mapping), one may not have chance to change the parent mapping. On Fri, Sep 26, 2008 at 11:52 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: Yes, but what about it? Assuming that you have the correct mapping, the appropriate behavior will happen On Fri, Sep 26, 2008 at 11:50 PM, Tuna Toksöz <[EMAIL PROTECTED]> wrote: I see Peter's point, an assembly which may be closed and another assembly which may add subclasses, isn't this a possible thing? On Fri, Sep 26, 2008 at 11:44 PM, Jon Palmer <[EMAIL PROTECTED]> wrote: There are two things going on in your scenario 1. Returning the correct type of mapped object 2. Filtering the rows due to legacy data. Returning the correct type of mapped object In The case that there is only one class NHibernate assumes every row in the table is of that class. It has no need to add the address_type_code to the select because it's going to build Addresses regardless of the value. It would be very strange (and I suspect broken) to expect Nhibernate to query for the rows and then only hydrate into Addresses those entries that matched the discriminator. In that situation the row Count of the sql query would could be different than the count of actual objects returned after hydration. Yuck. As soon as you add a subclass NHibernate will add the address_type_code column so that it can chose which class to create. I suspect that its entirely right it only does this when it needs to. Filtering the rows due to legacy data To remove you data that doesn't match address_type_code = home_address you should expect something to appear in the where clause. The alternative, that you query for everything and then cut down the results set during hydration rather than in the sql query, is likely to be ugly and perform extremely badly depending on the distribution of non home_address address rows. As I described in an earlier email, it's entirely right, indeed preferable, that NHibernate does not add the where clause when you query for the base class (as is always the case if there is only one class). Jon -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Lin Sent: Friday, September 26, 2008 12:37 PM To: nhusers Subject: [nhusers] Re: Discriminator bug sorry for the confusing explanations. I'll attempt to explain it better. Here is the situation. I. I have a table in a legacy database which has existing records which use the concept of a discriminator. In other words, there is a type_code column, which has different values. II. I have a C# object which represents an entity. The entity maps to records in the table with a specific discriminator value. III. I only want to get the records with a specific discriminator value from the table like "home_address". IV. I have a modeling tool which generates C# classes with the appropriate NH attributes. Changing the code gen for the special case to use one of the work arounds feels like a hack to me. V. since polymorphic queries require the discriminator column to create the correct object instance, shouldn't it always include it in the select part of the sql statement? thanks for taking time to listen and respond. peter On Sep 26, 3:20 pm, "Jon Palmer" <[EMAIL PROTECTED]> wrote: > If you have only one class mapped then the only thing it can return is > that one class so why would it need the address_type_code column? > > One of your previous emails indicated the problem was returning all rows > from the table. I'm confused about what the problem is your tryign to > solve. > > Jon > -- Tuna Toksöz Typos included to enhance the readers attention! -- Tuna Toksöz Typos included to enhance the readers attention! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
