-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Add Spark 3 SQL tests #1156
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
Add Spark 3 SQL tests #1156
Changes from all commits
a2dafe1
d2bc1da
5c9b929
66b7904
06c137e
20e5247
5414590
b34455e
58a9eb5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -155,7 +155,7 @@ public void testReplaceTableTxn() { | |
txn.commitTransaction(); | ||
|
||
Table table = catalog.loadTable(TABLE_IDENTIFIER); | ||
Assert.assertEquals("Partition spec should match", PartitionSpec.unpartitioned(), table.spec()); | ||
Assert.assertEquals("Partition spec should be unpartitioned", 0, table.spec().fields().size()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is any There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any partition spec with 0 fields is considered unpartitioned. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I should note that this needed to be updated because the spec's ID didn't match, causing the test to fail.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I supposed that was the reason for the change (spec's ID not matching). Thanks for the context! |
||
} | ||
|
||
@Test | ||
|
@@ -233,7 +233,7 @@ public void testCreateOrReplaceTableTxnTableExists() { | |
txn.commitTransaction(); | ||
|
||
Table table = catalog.loadTable(TABLE_IDENTIFIER); | ||
Assert.assertEquals("Partition spec should match", PartitionSpec.unpartitioned(), table.spec()); | ||
Assert.assertEquals("Partition spec should be unpartitioned", 0, table.spec().fields().size()); | ||
} | ||
|
||
@Test | ||
|
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'm not clear on whether this really should be the right behavior. Basically we're saying that a replace table will keep the existing location (as opposed to using defaults). I suspect we don't have create or replace with location semantics, but this is making some assumptions that a replacement is somehow the same as the old. If we were to go with id based pathing convention, this wouldn't work.
I don't think this is an issue at this point, but it might make sense to push this down to the location provider.
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 think this is correct because the
REPLACE TABLE
doesn't completely wipe out the old table. In most ways, it is the same table.Calling
buildReplacement
will replace the schema and partition spec so that the transaction can add a new snapshot. Table history, old snapshots, and existing table properties are kept so that you can inspect the table and don't need to add table configuration every time you run the SQL.We could add a flag to turn off this behavior and wipe out the old by default, but I don't think that's what users really want. It makes sense for things like default format and other settings to persist across replace operations, so that table configuration and table operations are orthogonal.
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.
ok, I guess that makes sense. I assumed the semantics to be the same a transactional
drop
andcreate
, but based on a little searching, it's much less clear than that. For example, with db2 create or replace will actually retain all data (assuming if aligns with the new table definition) by default.I agree that preserving table properties make sense, but wouldn't this wipe out comments (which we may also want to preserve)
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.
It would probably wipe out column comments. I'll have to fix that.