"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.

Attachment: pgpWWm1FAcGqB.pgp
Description: PGP signature

Reply via email to