-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[Connector API] Support soft-deletes of connectors #118669
base: main
Are you sure you want to change the base?
[Connector API] Support soft-deletes of connectors #118669
Conversation
Documentation preview: |
Hi @jedrazb, I've created a changelog YAML for you. |
…ub.com:jedrazb/elasticsearch into support-soft-deletes-connectors-change-mapping
@elasticmachine merge upstream |
Pinging @elastic/search-eng (Team:SearchOrg) |
Pinging @elastic/search-extract-and-transform (Team:Search - Extract & Transform) |
@elasticmachine merge upstream |
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.
Looks good! Just one comment about a possible test case.
Also, I'm curious about unique validations. Do we allow shared values across soft-deleted and live Connectors? E.g. can a new Connector have an index_name
value identical to a soft-deleted Connector?
@@ -279,4 +278,145 @@ setup: | |||
connector.list: { } | |||
|
|||
|
|||
--- |
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 could benefit from a test case covering when a connector was soft deleted and we don't want to see soft-deleted connectors in the list response.
so like
- Soft delete 1 connector
- Fetch with
deleted: false
- Ensure there are 2 results
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.
This exact scenario is covered here "List Connectors - Single soft deleted connector":
Be default the deleted
flag is false when not defined
Good point. By default, the logic stays the same, meaning deleted connectors remain invisible to any logic associated with existing connectors. |
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.
LGTM!
That was the single edge case I didn't cover because we have custom check (with query) for index names already in use ... fixed in 7525c99 |
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.
Left some comments, but I think nothing preventing this PR from being merged
@@ -27,6 +27,9 @@ To get started with Connector APIs, check out <<es-connectors-tutorial-api, our | |||
`<connector_id>`:: | |||
(Required, string) | |||
|
|||
`deleted`:: | |||
(Optional, boolean) A flag indicating whether to also include connectors that have been soft-deleted. Defaults to `false`. |
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.
(Optional, boolean) A flag indicating whether to also include connectors that have been soft-deleted. Defaults to `false`. | |
(Optional, boolean) A flag indicating whether to also return connectors that have been soft-deleted. Defaults to `false`. |
consistency nit
"deleted": { | ||
"type": "boolean", | ||
"default": false, | ||
"description": "A flag indicating whether to list connectors that have been soft-deleted." |
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.
"description": "A flag indicating whether to list connectors that have been soft-deleted." | |
"description": "A flag indicating whether to return connectors that have been soft-deleted." |
consistency nit, feel free to ignore if it makes sense to use "list" here
@@ -1138,6 +1159,11 @@ private Map<String, Object> getConnectorConfigurationFromSearchResult(ConnectorS | |||
return (Map<String, Object>) searchResult.getResultMap().get(Connector.CONFIGURATION_FIELD.getPreferredName()); | |||
} | |||
|
|||
private boolean getIsDeletedFromSearchResult(ConnectorSearchResult searchResult) { |
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.
private boolean getIsDeletedFromSearchResult(ConnectorSearchResult searchResult) { | |
private boolean isConnectorDeleted(ConnectorSearchResult searchResult) { |
I was a bit confused by the name in the beginning. Would isConnectorDeleted
make it more obvious?
@@ -212,6 +214,10 @@ public void getConnector(String connectorId, ActionListener<ConnectorSearchResul | |||
.setResultMap(getResponse.getSourceAsMap()) | |||
.build(); | |||
|
|||
if (isDeleted == false && getIsDeletedFromSearchResult(connector)) { |
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.
if (isDeleted == false && getIsDeletedFromSearchResult(connector)) { | |
boolean didNotFindNonDeletedConnector = isDeleted == false && getIsDeletedFromSearchResult(connector) | |
if (didNotFindNonDeletedConnector) { |
@@ -1156,8 +1182,8 @@ private static ConnectorSearchResult hitToConnector(SearchHit searchHit) { | |||
} | |||
|
|||
/** | |||
* This method determines if any documents in the connector index have the same index name as the one specified, | |||
* excluding the document with the given _id if it is provided. | |||
* This method determines if any records in the connector index have the same index name as the one specified, |
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.
Should it stay documents
here, if the next line uses docs
? Or should both be records
?
@@ -469,6 +479,7 @@ public void writeTo(StreamOutput out) throws IOException { | |||
out.writeEnum(status); | |||
out.writeGenericValue(syncCursor); | |||
out.writeBoolean(syncNow); | |||
out.writeBoolean(isDeleted); |
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.
Curious: do we need a new transport version, if we add something at the end of an entity, which is serialized over the wire? Does a potentially old node simply discard everything after syncNow
? Never tested that (I assume it works without a transport version check, but just to double-check)
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.
Should ConnectorTests
extend AbstractWireSerializingTestCase
btw as it can be serialized over the wire?
Soft deletes for connectors
Add support for soft-deletes of connectors. Why?
Changes
deleted
flag in the connector index mappings, indicates whether connector has been soft deleteddelete
,get
andlist
operations logic to support this featuredeleted=true
flag we return also deleted connectors in the responseRelated work
SystemIndexDecriptor
for connector indices soon, this will help updating mappings a lot as there is SystemIndexMappingUpdateServiceforce=true
to delete endpoint to completely remove the connector