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