wasabii commented on code in PR #4922:
URL: https://github.com/apache/calcite/pull/4922#discussion_r3300318442
##########
core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableTableModify.java:
##########
@@ -92,88 +97,304 @@ public EnumerableTableModify(RelOptCluster cluster,
RelTraitSet traits,
ModifiableTable.class.isAssignableFrom(
Types.toClass(expression.getType())),
"not assignable from type %s", expression.getType());
+
builder.add(
Expressions.declare(
Modifier.FINAL,
collectionParameter,
Expressions.call(
expression,
- BuiltInMethod.MODIFIABLE_TABLE_GET_MODIFIABLE_COLLECTION
- .method)));
+
BuiltInMethod.MODIFIABLE_TABLE_GET_MODIFIABLE_COLLECTION.method)));
+
+ final PhysType physType =
+ PhysTypeImpl.of(
+ implementor.getTypeFactory(),
+ getRowType(),
+ pref == Prefer.ARRAY ? JavaRowFormat.ARRAY : JavaRowFormat.SCALAR);
+
+ switch (getOperation()) {
+ case INSERT:
+ return implementInsert(implementor, result, builder, childExp,
collectionParameter, physType);
+ case UPDATE:
+ return implementUpdate(implementor, builder, childExp,
collectionParameter, physType);
+ case DELETE:
+ return implementDelete(implementor, builder, childExp,
collectionParameter, physType);
+ default:
+ throw new AssertionError("unsupported operation: " + getOperation());
+ }
+ }
+
+ /** Generates code for an UPDATE statement.
+ *
+ * <p>The child produces, for each row matched by the WHERE clause, a row of
+ * {@code tableFieldCount + M} fields:
+ * {@code [originalField_0, ..., originalField_N-1, newValue_0, ...,
newValue_M-1]}.
+ * The first {@code N} fields are the <em>entire</em> original table row (all
+ * columns, not just those being updated); the trailing {@code M =
+ * updateColumnList.size()} fields are the new values, one per column named
in
+ * the SET clause. Filtering by WHERE has already been applied upstream, so
+ * every source row corresponds to an existing row in the modifiable
collection
+ * and can be located by full-row content equality.
Review Comment:
Actually, I could do something like take the input update list, and ensure
that we only ever update one item in the target collection per item in the
update list. It's just a lot of complicated accounting, and I don't know if it
matter. It certainly doesn't for my use case for this (which is just minimal
UPDATE functionality so I can use ServerDdlExecutor as the backend for some
other projects test cases.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
