I may or may not allow for the "db value" of a converted enum to be used in place of the actual enum value. I would not hold your breath though - IMO it is not intuitive and not at all in the spirit of ORM .

As for Outer.Inner versus Outer$Inner.. comon folks. This is the exact syntax used by Java itself for the FQN of an inner class. How can using the exact syntax used by Java be "unexpected" and how can the opposite be preferable? That makes zero sense.

And as far as Outer.Inner.TYPE1 versus com.company.project.model.Outer$Inner.TYPE1 and the length, well that's because you cheated. You compared apples and oranges and concluded you prefer passion fruit. The apt comparison would actually be com.company.project.model.Outer.Inner.TYPE1 versus com.company.project.model.Outer$Inner.TYPE1. Now there is an aspect to this discussion wrt the length and qualification, but let's be logically consistent in discussing it. So..

In terms of FQN for an enum, I am going to stick with `$` over `.` for the reasons already stated above. So that means com.company.project.model.Outer$Inner.TYPE1 over com.company.project.model.Outer.Inner.TYPE1.

I've mentioned on other 6.0 discussions that I would also like to start formalizing other class references that users can "import" - which is the process that allows users to refer to an entity by its simple name in a query, e.g. Specifically I would like to allow constant references to be relative to an import name. What that means here would be that:

1. com.company.project.model.Outer could be imported and the literal could specify Outer$Inner.TYPE1
2. com.company.project.model.Outer$Inner could be imported and the literal could specify Inner.TYPE1

Additionally, in cases where we know that the "query node" represents an enum value literal reference, I'd like to at least look at allowing use of the unqualified enum value name. Here, that would mean the ability to just use TYPE1, again assuming that the context dictates that the node is enum valued.