Note: This issue is meant to capture a raw idea and design direction. It is not a concrete implementation plan and is likely not ready for execution unless someone already has a clear mental model of how to approach it.
At the moment, decisions in decisions4s can be evaluated into two main forms:
- Scala objects
- Textual representations (e.g. rendered expressions)
A potential extension would be to add a third evaluation target: SQL.
The core idea is to replace (or complement) Scala-level evaluation with SQL fragments, allowing decisions defined in code to be executed directly against database tables. This would make it possible to apply decisions to large datasets without pulling data into memory.
Initial direction
One possible starting point would be to reuse existing expression machinery and evaluate into something like:
This would allow rendering SQL from decision expressions in a relatively direct way. However, this is likely too low-level to be useful on its own — turning a table plus a decision into a meaningful SQL query probably requires additional structure, such as projections, joins, aliases, and query composition.
Still, this could serve as a first proof of concept to validate the general approach before introducing higher-level abstractions.
Open questions / concerns
-
Scope of SQL support
- A minimal starting point could support simple
SELECTs only.
- However, decisions conceptually could be used in
INSERT, UPDATE, or DELETE contexts as well.
- It’s unclear whether full DML support is desirable, or whether decisions should instead be embedded as subqueries or predicates and composed externally.
-
Abstraction level
Fragment-based rendering is flexible but very raw.- We may need a higher-level representation that can later be lowered into SQL, possibly database-agnostic at first.
-
Semantic fit
- How naturally do decision tables map to relational concepts?
- Are there decision constructs that fundamentally don’t translate well to SQL?
For now, the goal of this ticket is simply to record the idea and constraints, not to lock in a design. If someone wants to explore this space experimentally, even a narrow proof of concept would already be valuable.
At the moment, decisions in decisions4s can be evaluated into two main forms:
A potential extension would be to add a third evaluation target: SQL.
The core idea is to replace (or complement) Scala-level evaluation with SQL fragments, allowing decisions defined in code to be executed directly against database tables. This would make it possible to apply decisions to large datasets without pulling data into memory.
Initial direction
One possible starting point would be to reuse existing expression machinery and evaluate into something like:
This would allow rendering SQL from decision expressions in a relatively direct way. However, this is likely too low-level to be useful on its own — turning a table plus a decision into a meaningful SQL query probably requires additional structure, such as projections, joins, aliases, and query composition.
Still, this could serve as a first proof of concept to validate the general approach before introducing higher-level abstractions.
Open questions / concerns
Scope of SQL support
SELECTs only.INSERT,UPDATE, orDELETEcontexts as well.Abstraction level
Fragment-based rendering is flexible but very raw.Semantic fit
For now, the goal of this ticket is simply to record the idea and constraints, not to lock in a design. If someone wants to explore this space experimentally, even a narrow proof of concept would already be valuable.