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