Comment 2 for bug 839349

Thank you for a quick answer.

Here's some reasoning behind this request:
Well, the reason why we ask for this is because our domain model uses hard convention over configuration naming, so there's no problem for us to translate property name on the domain object to column name in database table. Also, in our project, we have quite many domain objects and most of the queries are performed through JPA/Hibernate, with some native SQL queries. We would like to use QueryDSL for native SQL queries too (because it's such a great tool :)) but we would like to avoid generating so much SQL query times seldom used. Therefore, we want to use QueryDSL alias feuture for those couple native SQL queries in that way, that instead of Path(s) for property names, we want to generate Path(s) for table column names just like in generated SQL query types. Therefore, we would appreciate to have alias feature configurable.

As for implementation, here are some possibilities, my first proposition was not good enough as our team leader advised to me - it exposes alias feature implementation using CGLIB (which may be changed later) to public API. So:
1) Your proposal is quite good for us with two small additions - we would also need to make AliasFactory.createProxy() protected, and also make PropertyAccessInvocationHandler more subclassing-friendly, allowing parts of creating PathMetadata for individual cases (GETTER, SCALA_GETTER, etc.) to be overwritten in a subclass (and keep the rest like metadata caching etc. private in superclass).
2) Something similar with slight difference - edit the PropertyAccessInvocationHandler class in the way explained above and to introduce some kind of pluggable strategy interface for handling PathMetadata creation itself.

What do you think about it? Or is there any better way to use QueryDSL for native SQL queries without generating SQL query types?