thanks for speaking up.
for me, adding the discriminator column is fundamentally more sound and supports a wider set of use cases. It's too bad such a simple idea met with such resistance when it can improve NHibernate. Other products don't take the perspective, since integrating with legacy systems is often a requirement. It's nice to know I'm not the only one who thinks the idea has merit. peter On Sep 27, 3:13 am, Stefan Nobis <[EMAIL PROTECTED]> wrote: > "Jon Palmer" <[EMAIL PROTECTED]> writes: > > 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). > > It depends on your viewpoint. You are right from a rather narrow, > NHibernate centric view, where your hbm.xml files are all you have to > consider. > > But from a broader and more abstract view, it's not really preferable, > because it breaks generalization. This generalization is important, as > was said before, if you have a larger toolchain than just NHibernate > and e.g. you want to do model driven architecture with tools that > generate hbm.xml and other code for you. These tools don't appreciate > special cases (but they could handle it), but what's more important: > Your big abstract model is no longer technology neutral, NHibernate > special cases leak into the design. > > And the big abstract design may be: we want be able to support > subclasses, but not in this iteration and maybe not be this team. We > want a design that handles legacy data and at the same time is > prepared to support subclasses later designed/developed/added by > another team without having to change our master design. > > This abstract goal is not supported with NHibernate (yes, you can make > workarounds for legacy data when there are no subclasses and yes you > can support superclass and subclasses in different assemblies -- but > supporting both with the subclasses only added at a later point in > time without changing the mappings for the superclass is not > possible). > > So, from an abstract point of view where NHibernate is not the one and > only technology/tool to consider I think, indeed, it's not prefereable > that NHibernat does not add the where clause. > > It's quite another question if the NHibernate team ever want's to > support this broader, non NHibernate centric point of view, because it > may be a cause of many headaches... but in this single case a simple > runtime configuration option may solve the problem and thus serve both > camps. > > -- > Until the next mail..., > Stefan. > > application_pgp-signature_part > < 1KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
