-
Notifications
You must be signed in to change notification settings - Fork 208
Description
Context
SqlTemplate provides a convenient abstraction for writing SQL with named parameters, but the SQL statement produced by a template is currently opaque to the user. Once a template is created, there is no supported way to inspect the prepared SQL it represents.
In practice, when templates are reused, composed, or built dynamically, understanding the exact shape of the generated statement becomes part of reasoning about application behavior. Without a way to observe the compiled SQL, users must rely on indirect mechanisms or internal knowledge to build that understanding.
Motivation
Being able to see the compiled SQL is sometimes important to validate that a template expands as intended and to align expectations between the application layer and the database layer. Today, this visibility is not available through the public API, which makes the abstraction harder to reason about in non-trivial cases.
Aim
The aim is to improve the transparency of SqlTemplate by allowing users to access the compiled SQL statement produced by a template. This would expose the prepared SQL text with placeholders, without interpolated values, and without changing execution semantics or safety guarantees.
Optional broader proposal
As a more general alternative, this capability could be addressed at the SQL client level rather than being specific to SqlTemplate.
One possible direction would be to expose two optional handlers in the SQL client lifecycle:
- a before-execution handler, invoked once the final SQL statement is known but before it is sent to the database, allowing inspection of the raw query;
- an after-execution handler, invoked after the database response is received but before result mapping and type conversion, allowing inspection of the raw result set(s).
Such hooks would provide a consistent and reusable way to observe query execution across all client usage patterns, including but not limited to SqlTemplate, while keeping concerns like logging, inspection, or analysis outside the core execution path.
Contribution
I able