ICriteria.List() fails silently for unmapped class
Description
Environment
is duplicated by
Activity
SandroM December 20, 2005 at 3:51 PM
Re: fixing it would break existing code
Really? Is there code that relies on ICriteria to return null for unmapped classes? Perhaps I'm missing something, but it seems like this would reveal buggy code. I definitely agree that backward compatibility is a concern though.
Re: write a message to the log (with log level of WARN or INFO) if a criteria query doesn't match any classes
Certainly better than nothing.
Re: Throwing an exception is something I don't want to do
What about not throwing an exception in Find() either then and returning null if the class isn't mapped? As you suggested, this path could also write a similar message to the log. This way the behaviour is consistent across all the possibilities and when the user solves the problem once, he knows where to look the next time.
My concern is that in learning NHibernate I had to figure out a bunch of different ways that objects could be loaded (Load, Get, Find, CreateCriteria), and two or three ways that each of those techniques could fail (various exceptions, returning null in some cases but not others, etc.). I'm trying to normalize the ways the queries can fail where the interfaces are more or less the same so the learning curve is shallower for future users.
A log message would definitely help; a consistent semantics would be better. I'll take what I can get.
Former user December 20, 2005 at 1:55 PM
Ok, I agree that it's an issue (probably shouldn't have resolved it as Not an Issue, but as Won't Fix), but I disagree that it's a major issue, and fixing it would break existing code. What I can do is write a message to the log (with log level of WARN or INFO) if a criteria query doesn't match any classes. Throwing an exception is something I don't want to do.
SandroM December 20, 2005 at 11:08 AM
Regardless of what the underlying reasons are, this seems like a serious usability issue. Why would you expect the user to understand the underlying mechanics of how NHibernate processes queries? If the class is unknown to NHibernate (ie. has no mapping), then it should throw an exception.
It's the Principle of Least Surprise. Unless there is an actual reason why these behaviours MUST be inconsistent, they should really be unified.
Former user December 20, 2005 at 9:56 AM
They fail differently because of different issues. The HQL one fails because it doesn't know the class and can't figure out what to do with it. The Criteria one returns an empty list because it knows the class and is actually looking for instances of the class or its descendants (a polymorphic query) and can't find any.
If you imported a class named MyImportedClass (even without mapping it) and used an HQL query "from MyImportedClass", you would get an empty list too.
Details
Details
Assignee
Reporter
Affects versions
Priority
Major
SessionFactory.OpenSession().Find("from Objects.ObjectType");
The above throws "NHibernate.QueryException: undefined alias or unknown mapping: Objects.ObjectType [from Objects.ObjectType]" if the class has not yet been defined in a mapping file.
SessionFactory.OpenSession().CreateCriteria(typeof(Objects.ObjectType).List();
The above returns null if the class has not been defined in a mapping file.
It would be much less surprising if the behaviour were consistent between the two (preferably the exception, but that's just my opinion).