Re: [hibernate-dev] SQM interpretation in my antlr-4-poc repo

Gunnar, to answer your "what should I work on?" question... there are lots of things still not supported and/or tested. At a high level... * UPDATE queries - are pretty much set in the grammar and SQM, but I do not remember writing any tests for those * INSERT queries[1] - I have not worked on implementing at all * JPA Criteria conversion to SQM - should be very straightforward, just needs doing. As for more atomic pieces... * Subqueries are initially implemented, but need some testing. Specific scenarios needing testing: uncorrelated subqueries, correlated subqueries, correlated subqueries with "join hoisting" * You mentioned the "collection function" support I just added. But we need to test these. I committed that stuff late last night and did not want to hold off waiting to write tests the next day. So these still need testing. Including validation against "strict JPQL compliance" if using one of the HQL specific ones. * Re-writing the "domain model" abstraction as discussed above and as we discussed on IRC. First coming up with a design acceptable to the "consumers" and then re-writing. * Spatial extensions. The main thing I am getting from the initial discussions with Karel is that the only real structure we (maybe) need to support here is literals. * Testing! I currently have 39 tests. 39. That's barely a beginning. I expect a lot of tasks to come out of writing tests. I think going through the current HQL tests and finding the things we want to support and porting tests is going to have to happen in some form at some point in time. [1] And I'd like to consider supporting the INSERT-tuple syntax in addition to the INSERT-SELECT syntax we already support. On Mon, Sep 21, 2015 at 1:47 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Just a heads up that I finally got enough traction in this work towards > building a "SQL AST" to warrant a push upstream. > > The majority of time has been trying to think through the best tree > structure for modeling from clauses especially in regards to > entity/collection persisters that map across multiple tables. So that is > where most of my work so far has gone. So far I have only worked through > handling entity persisters. You can see this contract > in org.hibernate.sql.orm.internal.mapping.ImprovedEntityPersister (which I > ultimately expect to augment the upstream EntityPersister contract with). > There are also some tests illustrating the structure that gets created for > various scenarios. So far I have only written tests for > SingleTableEntityPersister (which covers both no inheritance and > discriminator inheritance) with and without secondary tables. I will work > on expanding the covered scenarios as I have time during continued 5.0.2 > and 5.1 development. > > For those interested in taking a peek, the tree structure itself is > defined within the org.hibernate.sql.ast.from package. Be sure to see its > package-info for a high-level overview. > > The tests are in the org.hibernate.sql.orm.internal.mapping test package. > > > The next steps (after filling out the tested scenarios) is to start work > on resolving AttributeReferences from the SQM using > the TableSpecificationGroup as a means to resolve the specific table > aliases needed for each column. After that, building the rest of the tree > ought to be pretty straight forward. > > The other major task is to still account for "Dialect variance" (join > support, casting, etc). >