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