That is not how it works. The binding of sub classes is done on the config level, not in the SF.
On Fri, Sep 26, 2008 at 11:55 PM, Tuna Toksöz <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
