dimas-b commented on code in PR #1802:
URL: https://github.com/apache/polaris/pull/1802#discussion_r2124985836
##########
persistence/relational-jdbc/src/main/java/org/apache/polaris/persistence/relational/jdbc/QueryGenerator.java:
##########
@@ -37,35 +40,51 @@
public class QueryGenerator {
- public static <T> String generateSelectQuery(
+ public static class PreparedQuery {
+ private final String sql;
+ private final List<Object> parameters;
+
+ public PreparedQuery(String sql, List<Object> parameters) {
+ this.sql = sql;
+ this.parameters = parameters;
+ }
+
+ public String getSql() {
+ return sql;
+ }
+
+ public List<Object> getParameters() {
+ return parameters;
+ }
+ }
+
+ public static <T> PreparedQuery generateSelectQuery(
@Nonnull Converter<T> entity, @Nonnull Map<String, Object> whereClause) {
Review Comment:
to clarify: SQL text depends on two factors: operation (list, write, read,
etc.) and entity type. The latter is represented by java classes. We should be
able to keep a few pameterized SQL strings in those classes and use them
depending on the operation. I believe the SQL text can be defined at compile
time. The same classes can call `.prepareStatement(String)` to avoid any
ambiguity as to the source and content of SQL statements. Parameters will be
injected later with the help of classes representing entities - that would be
similar to current `toMap()` methods, but the keys/column names would be
implicit. Keeping SQL and param injection in the same class ensures that values
match placeholders.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
