We already had a few internal expression tree transformation utilities,
which can now be refactored in favour of more generic QOM transformation
tools. The refactoring includes:
- And::transform and Or::transform
- ANSI JOIN to Oracle (+) JOIN transformation (fixing some limitations)
This branch attempts not to create two separate type hierarchies.
Pros:
- "Switching" between DSL and model API is trivial, because no switch
- Model API can be used to construct new models using DSL API
- No new type name prefix needs to be invented, only method name prefix
Cons:
- "Polluted" QueryPart API can lead to friction for non-model API users
Also, avoid conflicts between DSL and model API by prefixing model API methods with $, also in QueryPart
Replace 3 valued Boolean types with enums:
- CycleOption
- RestartIdentityOption
Replace 3 valued Boolean types with boolean
- ToPublic (in Grant)
- FromPublic (in Revoke)
- Unique (in CreateIndex)
- Temporary (in DropTable)
Use API generator to generate Keywords / cleanup Keywords class
With the new MQueryPart.replace() functionality, a lot of internal expression tree transformations are no longer required, among which the AbstractCondition.unwrapNot utility that can transform things like NOT NOT P to P as is useful for a Teradata workaround (see [jOOQ/jOOQ#11857])
If a QueryPart has a special DSL constructor (e.g. to prevent unnecessary wrapping of parts, such as ConditionAsField(FieldCondition(x)) or FieldCondition(ConditionAsField(x)), then we should make sure that DSL constructor is used, not the actual constructor, at least in replace()
Revert wrong ConditionProviderImpl fix. join(..).on(..).and(..) depends on the previous behaviour, otherwise we lose the appended condition from the join convenience syntax
This draft includes:
- A QOM namespace containing the QOM API
- Lots of generated MQueryPart subtypes from our API generator
- Generated implementations of MQueryPart subtypes
- A draft MQueryPart traversal API
The current draft is not stable and will likely undergo heavy changes. Do not use this API yet for any production purposes (the existing DSL API is not affected, though)
DefaultAggregateFunction historically is for simple aggregate
functions without extra functionality, such as MIN, MAX, COUNT, SUM,
AVG. It was then used as a base implementation for various others, which
should be extending AbstractAggregateFunction, instead.
This refactoring will simplify further QOM work
