Btw, you fetch a FrontTire collection, but a tire isn't a fronttire (type wise). So you want to fetch fronttires, and you then can't fetch a supertype into that collection, as it's not a fronttire.
You can achieve what you want though by fetching a tire collection, and specifying a filter which says: NOT a reartire. You'll get a query which says something like:
WHERE
FrontOrRear != 'R' -- filter which you added and which says no rear tire
AND FrontOrRear IN ('B', 'R', 'F') -- filter added by the code which makes sure the particular type and all its subtypes are fetched.
Though I think what you should do is define 3 subtypes: (with an abstract Tire type):
FrontTire, RearTire and GenericTire. Because now a FrontTire is a subtype of a tire which can be a reartire as well, which is odd because it suggests FrontTire LOSES a specification through the inheritance, which is of course not correct: it inherits the specifications of the supertype, which says: can be rear OR front.
To specify NOT a reartire do:
public EntityCollection GetFrontTires(string styleCode)
{
EntityCollection frontTires = new EntityCollection(new TireEntityFactory());
RelationPredicateBucket filter = new RelationPredicateBucket();
filter.PredicateExpression.Add(RearTireEntity.GetEntityTypeFilter(true));
DataAccessAdapter adapter = new DataAccessAdapter();
adapter.FetchEntityCollection(frontTires, filter);
return frontTires;
}
I'll rethink the sematics of my code. It could still be a bug, but not in this situation.
(edit): not a bug, the query filters produced by llblgen pro is correct: it produces discriminator filters for the actual type to fetch AND all its subtypes. If there's just 1 value, there are no subtypes, so it works ok, and if there are subtypes, it will become an IN filter, which is also correct.