EQL3 Design Document

Abstract

The purpose of this document is to outline the main objectives of EQL3. This should cover both the improvements to existing EQL2 features and completely new capabilities that are not currently available.

One of the internal core changes for the EQL3 engine is the development of an algebrizer, which would in turn enable fancy optimisation of the resultant queries.

AST

http://astexplorer.net/

Main semantic differences between EQL3 and EQL2

• different joins approach -- EQL3 utilises bushy join trees to better reflect property requiredness within entity tree
• NULL literal instead of passing null values as JDBC parameters (caused CASTING errors in EQL2)
• literals for boolean (Y/N) and Integer values to reduce number of JDBC parameters (Long values are parameterised to gain performance with PreparedStatement in case of findById(..) method.)
• auto-yield in EQL2 always yielded all calculated properties (regardless of the actual need); auto-yield in EQL3 doesn't yield calculated properties if query is not result query (i.e. is source query), but maintains their expressions as part of query source metadata
• auto-yield in EQL2 yielded all properties of all implicitly joined tables (as part of where properties resolution) and adjusted group by statement if present; auto-yield in EQL3 no longer does this
• auto-yield in EQL3 implements fetch queries request minimisation by yielding 2-level sub-props together with 1-level props (present in fetch model)

Additional advantages of EQL3 over EQL2

• ability to mix aliased and not-aliased properties within a query (usability improvement)
• calculated properties are not yielded if not used (better performance)
• complex calculated properties work due to proper joins sequence
• better joins performance due to inner joins usage where appropriate
• ability to test final SQL at structure level (without query execution)
• implicitly calculated common union property sub-properties have context-aware expressions
• orderBy composite key orders by leaf members in all cases
• resolution context has proper upper boundary for calculated properties resolution
• enabled usage of correlated query sources
• calculated properties expressions are validated (resolved) during startup (early errors detection)
• UDF (User Data Filtering) API doesn't need query source alias (implemented at post-alias level) -- allows to avoid potential ambiguity errors
• enabled usage of correlated subqueries within select() queries (select from nothing queries)

Core features

• syntactical composition of queries/condition/expression/ordering models via Progressive (Fluent) Interfaces
• dot.notation in prop(..) operator -- implicit generation of all missing SQL joins
• calculated properties
• auto-yield -- implicit generation of all yields based on the context and query type
• condition auto-ignore with iVal(..)/iParam(..) operators
• UDF (user data filtering) -- implicit adjusting of main query source criteria based on the current user

Outstanding issues

• adjust auto-yield to skip some types of implicitly calculated properties (composite key, union property common subproperties)
• in case of explicit yields remove those not contained within fetch model (as EQL2 does)