Skip to content

Return number of deleted rows from Iceberg metadata delete#12136

Merged
findepi merged 1 commit intotrinodb:masterfrom
homar:homar/return_number_of_deleted_rows_from_iceberg_metadata_delete
Apr 27, 2022
Merged

Return number of deleted rows from Iceberg metadata delete#12136
findepi merged 1 commit intotrinodb:masterfrom
homar:homar/return_number_of_deleted_rows_from_iceberg_metadata_delete

Conversation

@homar
Copy link
Member

@homar homar commented Apr 26, 2022

Description

Related issues, pull requests, and links

fixes #12055

Documentation

( ) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

( ) No release notes entries required.
( ) Release notes entries required with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

@cla-bot cla-bot bot added the cla-signed label Apr 26, 2022
@homar homar requested review from alexjo2144 and findepi April 26, 2022 09:00
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When can the information be missing?

if it can actually be missing, we should return empty instead of 0,
but maybe it's guaranteed to exist and then we just should get and check?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure? I actually think that it is better to return 0, it is more consistent for me when all deletes return information in the same way. Even tests show this as in current state this passes:
assertUpdate("DELETE FROM " + tableName + " WHERE key = 'three'", 0);
and it won't pass with the proposed change.
even this will fail:
assertQueryReturnsEmptyResult("DELETE FROM " + tableName + " WHERE key = 'three'");
with:
java.lang.AssertionError: [Rows for query [DELETE FROM test_delete_returns_number_of_rows_1npq8u144q WHERE key = 'three']] Expecting empty but was:<[[null]]>

@findepi WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When can the information be missing?

When nothing is deleted this property is not set.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

information in the same way. Even tests show this as in current state this passes:
assertUpdate("DELETE FROM " + tableName + " WHERE key = 'three'", 0);
and it won't pass with the proposed change.

use assertUpdate("DELETE..."); (remove , 0) there

When nothing is deleted this property is not set.

Sounds like something that we should be possible to fix.

Until it's fixed, i don't want to rely on a quirk that lack of DELETED_RECORDS_PROP means "0 rows affected".
That sounds like relying on an impl detail.

@homar homar force-pushed the homar/return_number_of_deleted_rows_from_iceberg_metadata_delete branch 2 times, most recently from 4583080 to 72e6d0d Compare April 26, 2022 15:13
@alexjo2144
Copy link
Member

Can you remove the two test overrides in BaseIcebergConnectorTest now? https://github.com/trinodb/trino/blob/master/plugin/trino-iceberg/src/test/java/io/trino/plugin/iceberg/BaseIcebergConnectorTest.java#L242

@homar homar force-pushed the homar/return_number_of_deleted_rows_from_iceberg_metadata_delete branch from 72e6d0d to 423e446 Compare April 27, 2022 09:43
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make Iceberg fill DELETED_RECORDS_PROP always?
let's file a PR and link with a TODO note here.

Comment on lines 3437 to 3438
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make Iceberg fill DELETED_RECORDS_PROP always?
let's file a PR and link with a TODO note here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for adding a TODO note. Can it contain a link?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a pr yet. Should I open an issue? What if they decide to close it ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's have an issue.

even if it gets closed, it will serve as an anchor for further information and current status

@homar homar force-pushed the homar/return_number_of_deleted_rows_from_iceberg_metadata_delete branch 2 times, most recently from 7b5578f to bc55515 Compare April 27, 2022 12:47
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@findepi findepi force-pushed the homar/return_number_of_deleted_rows_from_iceberg_metadata_delete branch from bc55515 to 728ffbc Compare April 27, 2022 12:55
@findepi
Copy link
Member

findepi commented Apr 27, 2022

CI #12151

@findepi findepi merged commit de4a4ab into trinodb:master Apr 27, 2022
@findepi findepi mentioned this pull request Apr 27, 2022
@github-actions github-actions bot added this to the 379 milestone Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

Return number of deleted rows from Iceberg metadata delete

3 participants