quote Jörg Hohwiller Actually I would consider the spec to be buggy. It is absolutely not DRY (do not repeat yourself) to require FQN here. In that context the qualified enum type is already known. The name of the enum constant would be fully sufficient.
This gets into language parsing as well as the JPA design of AttributeConverter. Take a query like select p from Person p where p.sex = MALE and assume Person#sex is an enum value with a named value MALE... Yes the type of the "parse node" MALE can be known relative to its relationship to the p.sex parse node. That's not always the case, but here it is and for now lets assume it is always determinable thusly. So given the AttributeConverter contract as defined by JPA, how would one "consume" the String "MALE" into a value of type Sex? Generically speaking.. And in terms of parsing, its simply less efficient/performant to handle this case. If the MALE is fully qualified I can know immediately that it is a literal. If it is not, then I have to treat it generally and resolve it later. In general I would be ok with exploring support for unqualified enum literal references in the query. This would certainly be:
- an enhancement
- beyond the scope of JPA (provider portability)
It's not something I am going to spend a lot of time on right now. We are however currently rewriting the query parser, so I will consider ways to possibly allow this in the new parser. |