[hibernate-dev] [HSEARCH][V6-POC] Syntax for query building

Hello, In Search 6, we are changing the Query DSL APIs to move away from Lucene dependencies. Since this breaks backward compatibility whatever we do, we had a look to improve the the syntax a little bit with some other changes. In particular, for query predicate building, we experimented with three syntaxes when it comes to nesting: - a fully-fluid syntax, allowing nested predicate definition through chained calls (and potentially an ".end()" call where necessary to get back to the parent predicate). - a lambda-based syntax, allowing nested predicate definition by passing lambdas that create the nested predicate. - an "object-based" syntax, allowing to create an object representing your predicate, and then pass it as an argument to another predicate to nest it. This is pretty similar to the QueryBuilder syntax in Search 5. In the showcase module of the proof-of-concept ( https://github.com/hibernate/hibernate-search-6-poc/tree/master/integrati...), I included multiple implementations of the DAOs to demonstrate various syntaxes. Since the fully-fluid syntax does not allow to handle conditions or loops within a single chained call, some of the implementations actually mix multiple syntaxes: - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.object demonstrates pure "object-based" syntax - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.lambda demonstrates pure "lambda-based" syntax - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandlambda demonstrates fluid syntax resorting to lambda-based syntax when conditions or loops are necessary. - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandobject demonstrates fluid syntax resorting to object-based syntax when conditions or loops are necessary. My questions: - Do all of these query building syntaxes make sense to you? - Do you think we need all of them? - Is one better than the others? Some elements of thought: - There may not be a "one-size-fits-all" solution; I personally like the "fluid" syntax best for "shallow" queries with little to no nesting, and the "fluid+lambda" syntax best for deeply nested queries. To make your own opinion, you can have a look at implementations of "DocumentDao#searchAroundMe" for a query with complex nesting, and at implementations of "LibraryDao#search" for a "shallow" query. - Purely lambda or purely object syntax, in my opinion, are more verbose. The syntax feels more "to the point" where we can use chained calls (fluid syntax). - The fluid syntax is not very IDE-friendly when nesting predicates, as code formatting will ignore the implicit structure of chained calls (it will remove indents that previously made nesting obvious). - With lambdas being regularly advised against for various reasons, we might want to offer at least one other way of doing things. -- Yoann Rodiere yoann(a)hibernate.org / yrodiere(a)redhat.com Software Engineer Hibernate NoORM team