[hibernate-dev] Query handling : Antlr 3 versus Antlr 4

[Steve Ebersole]

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.