Re: [hibernate-dev] Query handling : Antlr 3 versus Antlr 4
On Wed, Jun 17, 2015 at 7:39 AM Gunnar Morling
Yes, having such extension point seems reasonable. OGM would probably
use
the same implementation as ORM, but other users may plug in another impl
based on their own type of entity definitions. Would the scope of that
extension point be solely attribute resolution or also handling of other
things such as literals? I'd hope the latter could be done in a unified way
by the parser?
That would be my preference as well. I think it makes the most sense to do
this stuff once in a single place. Some specific capabilities we would
need:
1) Ability to resolve "entity description" based on query token, including:
1.a) handling of "query imports" (aka, "MyEntity" ->
"com.acme.MyEntity")
1.b) polymorphic query references (i.e., "from java.lang.Object")
2) Access to "Attribute descriptors", ideally hooked into "entity/type
descriptors".
3) General classloading (Java/Enum constant/literal resolution)
These things combined would allow us to perform all the generic semantic
validations we need.
Much of this is in place already.
I am not sure in terms of exact types to be returned, but it'd help if the
returned structure contained information about the actually affected
"tables" (or more generally, "structures" in the query backend), so
that
users don't each have to deal with resolving that information wrt. the
current mapping strategy. That need some extension point for specifying the
sub-types of given types. Again, OGM would probably share an impl. with ORM.
At the moment this is handled
via org.hibernate.hql.parser.model.PolymorphicEntityTypeDescriptor which is
an extension to EntityTypeDescriptor. E.g., in the query "from
java.lang.Object" we'd report back PolymorphicEntityTypeDescriptor that
aggregates all root entities. The parser can always just deal with the
TypeDescriptor abstractions.