redesign query execution

[gavinking]

For almost as long as I remember, I’ve been sort-of unhappy with how Query objects work in Hibernate. There’s various sources of my discomfort, but they include:

• I need a Session to create one. I can’t just go and call an arbitrary function to make on, nor store one in a static variable.
• I can’t typecheck the query until I try to execute it, unless I use a named query, and that comes with its own sources of discomfort.
• The Query object is mutable, for no especially convincing reason.
• “Typed” queries have always felt uncomfortable: either I pass in a class object when I create the query, or I let the type be inferred from what I assign it to. Neither of these options is perfect.
• We’ve polluted the Session interface without about a million methods for creating queries of all sorts.
• We have a bit of a problem in dealing with “typed” queries vs “untyped” queries in Hibernate at the moment, where “untyped” queries tend to produce compiler warnings. (This is better in Reactive, because we don’t have the inheritance from EntityManager to deal with.
• The system isn’t very extensible: it’s hard to add new sorts of query facilities.

Tonight it struck me that I’ve been being extremely dense about this, and that the solution has been pretty much staring me in the face all along.

This is perhaps going to look a bit crazy at first, but hear me out:

1. You should instantiate query objects using new, and
2. then call methods on it to set parameters and such-like, where each call returns a new immutable object, and then finally
3. you should execute the query by calling a method on the query object, and passing in the session as an argument.

For example:

    List<Person> people = 
            new HqlQuery<Person>(“from Person where name=:n”)
                    .with(“n”, name)
                    .resultList(session);

whether you specify the type using <Person> or by passing in Person.class us up to you, and a matter of taste, I don’t care. Of course you can still use a raw type if you prefer.

A native query would work similarly:

    List<Person> people = 
            new SqlQuery<Person>(“select * from Person where name=:n”)
                    .addEntity(Person.class) 
                    .with(“n”, name)
                    .withMaxResults(100)
                    .resultList(session);

or:

    List<Person> people = 
            new SqlQuery<Person>(“select * from Person where name=:n”)
                    .withResultSetMapping(resultSetMapping) 
                    .with(“n”, name)
                    .withMaxResults(100)
                    .resultList(session);

and you can guess what this looks like for criteria queries, or for Max’s favorite tuple stuff.

That’s all fine, I think, but where this really starts to look nice is for something like this:

    SqlQuery<Person> personByName = 
            new HqlQuery<Person>(“from Person where name=:n”)
                    .validate(sessionFactory);

    List<Person> runIt(String name, Session session) {
        return personByName.with(“n”, name)
                    .resultList(session);
    }  

I think this is an idea worth exploring.

[gavinking]

It's important to realize that this proposal has exactly zero impact on existing APIs, and comes with no cost in terms of backward-compatibility.

At least in the initial implementation, resultList(Session) would just call back to the existing methods of Session.

[beikov]

So HqlQuery#validate will produce a SqlQuery? Or is this just a typo in your example? Maybe you could start out with defining some of the types you imagine so we can better understand what you were thinking about?

First of all, let's acknowledge that internally, we have a contract called QueryPlan and it's various subclasses which model translated queries that can be executed. One complexity here is that there is not always a 1:1 translation from HQL/SQM to SQL because multi-valued parameters, lock modes etc., which are given by QueryOptions of a DomainQueryExecutionContext, affect the generated SQL string, so we would IMO first need some kind of intermediate representation that can't be changed anymore based on input values. I guess internally, we model this as a JdbcOperation.

I think the idea of having an immutable query object is interesting, but I think we have to define some expectations. It seems to me that the HqlQuery you are imagining is a lot like a named query, except that the validation is explicit/deferred.

Let's classify the existing representations we have to understand what this new thing could be.

	org.hibernate.Query	QueryPlan	JdbcOperation	NamedQuery	HqlQuery
mutable	yes	no	no	no	no
parametrizable	yes	yes	partly	yes	yes
attached	yes	yes	yes	yes	no
validated	partly	yes	yes	yes	no

• mutable - Classify whether the object can be altered and it is thus not usable for caching
• parametrizable - Classify if parameter values change be changed. Partly means yes, but multi-value arity may not change
• attached - Classify if the object is bound to a Session/SessionFactory
• validated - Classify if the object is semantically valid

If I understand correctly from this classification, this HqlQuery AFAIU is like a NamedQueryFactory?

[gavinking]

Yeah, sure, something along those sort of approximate lines.

[sebersole]

Agreed that there is just not enough detail here to give you an opinion.

Is it interesting? Is it really that big of a deal? 🤷

[beikov]

If my understanding/classification aligns with your ideas, then I am not so sure how much value this brings on the table as this would be solely convenience, but I'm not against it.

[gavinking]

I agree that this would perhaps not be worth doing in the abstract. I don't typically like having too many ways to do the same thing: it creates confusion and inconsistency.

(OTOH, being able to easily separate query construction + validation from execution really is actually pretty useful.)

But there's a more practical reason I would like to do it: I'm pretty worried that it's going to be almost impossible to really properly fix the issues listed in discussion #4454 without breaking a lot of existing user code.

Now if we introduce an alternative shiny new API that has the freedom to just jettison all the baggage of ancient versions of Hibernate, and of JPA—that lets us start with a clean slate—then the problems with the existing Query API perhaps just aren't so acute anymore, and we can stick with a sort-of minimalistic set of fixes that doesn't break existing clients. (The fixes I'm currently working on in a branch.)

But in the absence of a clean slate, I would feel like we need to do something slightly more radical in terms of reworking the existing API, and it's hard to see what we could do that wouldn't break people.

[beikov]

But there's a more practical reason I would like to do it: I'm pretty worried that it's going to be almost impossible to really properly fix the issues listed in discussion #4454 without breaking a lot of existing user code.

I believe we came to the conclusion that the issues you describe in #4454 are fixable. The only "issue" is we have to choose between a naming problem or a source compatibility problem for users. I don't know though if a new clean state API is the answer to the problems of #4454

I'd rather see us fix #4454 first and then reconsider this proposal.

[gavinking]

So, this wasn't a terrible idea, and if we were starting from scratch, I would still consider it. But recent work has gone in a kind of different direction, and some of the issues above have been addressed in other ways.

I'm going to close this.