I agree using an abstract base class could solve the issue. Unfortunately, our modeler doesn't support abstract classes currently. When I worked for IBM Ascential, we supported abstract classes through UML models. for those not familiar with IBM's metadata server, it's part of IBM's information server product http://www-01.ibm.com/software/data/integration/info_server/
the only issue I see with using the abstract class approach is it may not work well with existing database with dirty data. For a new system, NHibernate would never save a row with the discriminator value for the abstract class, therefore polymorphic queries will work correctly. the issue I see with a legacy system is that I can't gaurantee a customer's database won't have data with the discriminator value. Say I make the discriminator value for the abstract class NULL. If one of the customers has NULL for the discriminator column, NH would try to create an instance of the abstract class and blow up. Assuming we update the modeling tool to support abstract classes, I would need to choose a discriminator value that no customer would ever use, to prevent NH from trying to instantiate an instance of the abstract class. I remember seeing an existing jira related to abstract classes and discriminators. Has that changed, or can an abstract classes declare a discriminator without a default value? I've never tried it, so I'm hoping someone else knows the answer. peter On Sep 26, 5:00 pm, "Tuna Toksöz" <[EMAIL PROTECTED]> wrote: > Right, going for abstraction will solve this issue. > > On Fri, Sep 26, 2008 at 11:54 PM, Jon Palmer <[EMAIL PROTECTED]>wrote: > > > > > 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! > > -- > 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 -~----------~----~----~----~------~----~------~--~---
