Hi!

There is one thing I'd find REALLY usefull in my project: filter subclasses. How do I do this?

I have a <joined-subclass> and I'd like to apply a filter that makes sure this class is only instantiated based on a column value.
This is easy and works very good on normal classes, how come the DTD won't allow me to define a filter on the subclass? Is it not possible to apply filters on subclasses no matter what strategy for inheritance mapping one uses?
I'd really like to avoid making this into some kind of collection filter.

Kristin

I've been pondering this for a while, and I guess I know what the reply (if any) to my previous post will be.
In the discussions I've read about filters it is claimed that "the essense" of filters are that they are applied to plural data such as collections and classes to be generated from a subset of data. And that applying a filter to the many side of a relation (or indeed one-to-one) is totally of the bend for what a filter is supposed to do (and therefore the adherrent one-to-one between the tables in an inheritance implementation).
But is this really fair? I can explain my use case (pardon my english if it complicates the description):
I have an object Code with a varierty of properties and relations to other entities. But I want to add language support for the different Code entries, so I have a table CodeLanguage that holds a reference to Code and has the string language entry for the code (typically used in GUI). Now... when other entities or the GUI needs to reference a Code it would really be nice to:

Have object Code simply return the string for the code according to the language set for the application at runtime. But since there are many language implementations the Code object would have to hold a collection of CodeLanguage and iterate over this getting the language according to what is currently set. You could of course specify a HQL and return an object with the specific properties needed, but I want to reuse my domain objects.

What would be nice is if I could instead use a filter, so that I could have a one-to-one relationship between Code and CodeLanguage, simply returning the Code for the language currently set. Or better yet:
Make Code the object persisted by CodeLanguage, spesify a superclass for the Code persisted by the previous Code-implementation, make a filter take care of always instantiating the right Code object for current language, and voila simply hide complcations adherring to language. (The language to use would of course be set by some form of advice).

Hehe, this was longish, but please reply if you think you know how this sould be solved or you think I'm a complete wierdo.
And before you say it: no I cannot simply fusion Code and Language into one table making the language porperty part of the key. Many resons for this, legacy being one thing.

Kristin :)