-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds DML (INSERT, DELETE, UPDATE, UPSERT, REPLACE) #1666
Conversation
* TODO | ||
*/ | ||
@Nullable | ||
public final List<Identifier> columns; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Syntactically, could a FromDefault
also include a list of columns
? I couldn't find if there was this restriction from the RFCs. The EBNF seems to indicate there could be a list of columns with a DEFAULT VALUES
specified:
<upsert statement> ::= UPSERT INTO <table name> [ AS <alias> ]
[ ( <attr name> [, <attr name> ]... ) ]
<values>
...
<values> ::= DEFAULT VALUES | <values clause>
| <bag value> | <sub-select>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See partiql/partiql-lang#95. I meant to cut an issue earlier, but the modelling in the RFCs is very likely wrong (and it's also unspecified). That being said, this PR adds the correct modelling while also allowing for the addition of the insert column list in the future if it is eventually specified. And, the ANTLR grammar can be updated accordingly. But for now, looking at the SQL:1999 EBNF in contrast with the RFC's EBNF, it is immediately apparent that one is wrong.
Removes InsertColumnList AST node Fixes the passing of some AST children Updates Javadocs Adds tests for explicit use of ROW
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the detailed work adding DML to the new AST -- think we're almost there.
*/ | ||
@Builder(builderClassName = "Builder") | ||
@EqualsAndHashCode(callSuper = false) | ||
public final class Insert extends Statement { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the idea is that these DML statements do have shared functionality in being DML statements. Yingtao had done a similar thing for DDL statements:
partiql-lang-kotlin/partiql-ast/src/main/java/org/partiql/ast/ddl/CreateTable.java
Line 20 in 51f4ad1
public class CreateTable extends Ddl { |
It can make it a bit easier to case on the statements to apply the same logic to DQL, DML, DDL. Whatever we choose, we should try to be consistent (i.e. have DDL and DML have separate abstract classes or have the statements directly extend Statement).
*/ | ||
// TODO: Should this be a list of identifiers? Or paths? Expressions? | ||
@NotNull | ||
public final List<Identifier> indexes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So does <attr name>
in the RFC (https://github.com/partiql/partiql-lang/blob/main/RFCs/0011-partiql-insert.md?plain=1#L123) refer to Identifier
or IdentifierChain
AstNode
? In the other comment (#1666 (comment)), <index attr name>
is an <attr name>
which we then define as an IdentifierChain
.
I'm thinking if we're inclined at all to classify it as an IdentifierChain
in the AST, it is more backwards compatible API-wise since an IdentifierChain
without a next
is just an Identifier
.
partiql-ast/src/main/java/org/partiql/ast/dml/ConflictTarget.java
Outdated
Show resolved
Hide resolved
From the most recent changes (may also apply to earlier changes), there are some conformance tests failing -- https://github.com/partiql/partiql-lang-kotlin/actions/runs/12205681348. |
Adds SqlDialect for the DML statements Fixes the getChildren for multiple DML AST nodes Updates Javadocs to reference unimplemented, future features
Adds the conversion for ExprValues to a plan node
Alright! I fixed the table value construction issue with the conformance tests, and for the other 4 remaining failing tests, I believe those tests are actually wrong. See partiql/partiql-tests#130 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pre-approving following rebase from v1
. Thanks for the deep dive into adding DML along with all the partiql-lang
issues!
Regarding the conformance test failures, seems very likely that's an error in the conformance tests, but we should look more into it. Since it doesn't affect the public APIs, we could figure things out in a later work stream.
/** | ||
* TODO | ||
*/ | ||
// TODO: Change this to a literal, not an ExprLit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The updated literal modeling (#1650) has been merged in, so we can address this TODO. Think we'll have to otherwise build will fail.
Relevant Issues & Links
Description
ExprRow
and the table value constructor (VALUES ..., ...
). If you want, you can manually invokediff
to see what's different betweenDQL
andPartiQLParser
, but it's really just a removal of the DML.FROM INSERT
,FROM SET
,FROM REMOVE
, andRETURNING
AST nodes since they are not SQL Spec and are not used by active customers. Please see the issues that reference this PR further below.License Information
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.