[
https://issues.apache.org/jira/browse/CALCITE-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15726586#comment-15726586
]
Julian Hyde commented on CALCITE-1527:
--------------------------------------
Regarding {{VALUES}}. We may need to implement different syntax for different
dialects, e.g. {{SELECT .. UNION ...}}. But {{VALUES}} is the standard one, so
we should use that if the dialect supports it.
Did you know that you can use {{VALUES}} outside of {{INSERT}}? For example,
{{VALUES 1 + 2}} is equivalent to {{SELECT 1 + 2}}. This is why I don't think
we should treat {{INSERT ... VALUES}} separately; we'll get it if we implement
{{INSERT ... <relational expression>}}. I think {{SQL_INSERT_VALUES_OPERATOR}}
can go.
If tests are mutating state, I don't think that ordering tests is a good
solution. It will break if we run tests in parallel, for instance. Could you
use {{Schemas.uniqueTableName}} or a similar approach? If table names are
unique then the tests won't bump into each other. The test suite should clean
up after itself, and make sure it has a clean initial state before it runs.
Or maybe if tests don't commit, transaction isolation will deal with everything.
> Support DML in the JDBC adapter
> -------------------------------
>
> Key: CALCITE-1527
> URL: https://issues.apache.org/jira/browse/CALCITE-1527
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
> Reporter: Christian Tzolov
> Assignee: Julian Hyde
>
> Currently the JDBC adapter does not support the DML operations: *INSERT*,
> *DELETE* and *UPDATE*.
> Solution needs to convert the parsed *Modify* and *Values* RelNodes into
> *JdbcTableModify*, *JdbcValues* ... such and then in turn into corresponding
> SqlInsert, SqlUpdate and SqlDelete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
