Skip to content

Add support for convering keys to lowercase/uppercase in RenameKeyProcessor#5810

Merged
kkondaka merged 3 commits intoopensearch-project:mainfrom
kkondaka:rename-keys-case
Jun 24, 2025
Merged

Add support for convering keys to lowercase/uppercase in RenameKeyProcessor#5810
kkondaka merged 3 commits intoopensearch-project:mainfrom
kkondaka:rename-keys-case

Conversation

@kkondaka
Copy link
Copy Markdown
Collaborator

Description

Add support for convering keys to lowercase/uppercase in RenameKeyProcessor.
Reused existing TransformOption in KeyValue processor in RenameKeyProcessor.

Addresses part of the issue #5757

Issues Resolved

Check List

  • [X ] New functionality includes testing.
  • New functionality has a documentation issue. Please link to it in this PR.
    • New functionality has javadoc added
  • [ X] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

…cessor

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>
Comment on lines +45 to +49
boolean entriesProvided = config.getEntries() != null;
boolean transformOptionProvided = (transformOption != null && transformOption != TransformOption.NONE);
if ((!entriesProvided ^ transformOptionProvided)) {
throw new InvalidPluginConfigurationException("Only one of 'entries' or 'transform_key' should be specified.");
}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think, it is Ok to have this logic here but we should also have this validation in the RenameKeyProcessorConfig so that it gets caught early on.


boolean entriesProvided = config.getEntries() != null;
boolean transformOptionProvided = (transformOption != null && transformOption != TransformOption.NONE);
if ((!entriesProvided ^ transformOptionProvided)) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's be consistent by adding the assertions in the config files.

e.g.

@AssertTrue(message = "match and from_time_received are mutually exclusive options. match or from_time_received is required.")
boolean isValidMatchAndFromTimestampReceived() {
return Boolean.TRUE.equals(fromTimeReceived) ^ match != null;
}

throw new InvalidPluginConfigurationException("Only one of 'entries' or 'transform_key' should be specified.");
}
if (config.getEntries() == null || config.getEntries().size() == 0) {
return;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This could be error prone. It is assuming that no code below does anything else of importance.

Instead:

if(config.getEntries != null) {
  config.getEntries().forEach(...

I do think short-circuit returns are good for functions. But, not for constructors which operate differently.


private void transformEvent(final Event event, Map<String, Object> map, final String keyPrefix) {
for (Map.Entry<String, Object> entry : map.entrySet()) {
Object result = null;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't think this is used.

assertThat(editedRecords.get(0).getData().containsKey("key2"), is(true));
assertThat(editedRecords.get(0).getData().containsKey("key2/key3"), is(true));
assertThat(editedRecords.get(0).getData().containsKey("key2/key3/key4"), is(true));
assertThat(editedRecords.get(0).getData().containsKey("key2/key3/key5"), is(true));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Also assert that the old keys are not present.

Copy link
Copy Markdown
Collaborator

@san81 san81 Jun 23, 2025

Choose a reason for hiding this comment

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

Can we have one more test case to validate the logic in (!entriesProvided ^ transformOptionProvided) Like to test this validation part

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>
san81
san81 previously approved these changes Jun 24, 2025

ReflectivelySetField.setField(RenameKeyProcessorConfig.class, renameKeyProcessorConfig, "entries", entries);
ReflectivelySetField.setField(RenameKeyProcessorConfig.class, renameKeyProcessorConfig, "transformOption", TransformOption.LOWERCASE);
assertFalse(renameKeyProcessorConfig.isValidConfig());
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

These should all be separate @Test methods because they are different tests.

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>
@kkondaka kkondaka merged commit 69bff61 into opensearch-project:main Jun 24, 2025
49 of 51 checks passed
@dlvenable dlvenable added this to the v2.12 milestone Jun 24, 2025
@kkondaka kkondaka deleted the rename-keys-case branch July 1, 2025 17:04
JonahCalvo pushed a commit to JonahCalvo/os-data-prepper that referenced this pull request Jul 17, 2025
…cessor (opensearch-project#5810)

* Add support for convering keys to lowercase/uppercase in RenameKeyProcessor

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>

* Addressed review comments

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>

* Addressed review comments

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>

---------

Signed-off-by: Krishna Kondaka <krishkdk@amazon.com>
Signed-off-by: Jonah Calvo <caljonah@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants