Rework QL to streamline many signatures and reuse recurring parts.
Grouping of Functionality
Recurring methods have been moved into aptly named interfaces (And, Columns, OrderBy, ...). This allows for a cleaner grouping of related functionality. This makes it easier for us to streamline behaviour between various ways to express the same thing (SELECT.from(x, COLUMNS), SELECT.from(x).columns(COLUMNS), etc).
Interface Declaration Merging
Query flavours that should offer methods from the interfaces mentioned above can just pull them in via declaration merging:
// following code is slightly simplified!
interface SELECT implements And, Columns {}
class SELECT { } // instances of SELECT now offer the methods from And and Columns even without explicitly declaring them
Stricter Types
Types have been strictened where possible. Especially .columns and its various manifestations now try to actually derive the columns from valid properties:
SELECT.from(Books).columns('author') // author being auto completed
The same has been attempted for .where/ .having. Best we can offer there is a sporadic error when the parameters are total bogus.
@mariayord this PR is quite excessive as it is a fundamental rewrite. I guess it needs a lot of testing to make sure no overload that was allowed before got lost... we can surely have a look together if you'd like.
Rework QL to streamline many signatures and reuse recurring parts.
Grouping of Functionality
Recurring methods have been moved into aptly named interfaces (
And
,Columns
,OrderBy
, ...). This allows for a cleaner grouping of related functionality. This makes it easier for us to streamline behaviour between various ways to express the same thing (SELECT.from(x, COLUMNS)
,SELECT.from(x).columns(COLUMNS)
, etc).Interface Declaration Merging
Query flavours that should offer methods from the interfaces mentioned above can just pull them in via declaration merging:
Stricter Types
Types have been strictened where possible. Especially
.columns
and its various manifestations now try to actually derive the columns from valid properties:The same has been attempted for
.where
/.having
. Best we can offer there is a sporadic error when the parameters are total bogus.