-
Notifications
You must be signed in to change notification settings - Fork 211
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
Opensearch Sink: refactor all index related operations into IndexManager classes for easier future extension #361
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
103 changes: 0 additions & 103 deletions
103
...ch/src/main/java/com/amazon/dataprepper/plugins/sink/opensearch/IndexStateManagement.java
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
15 changes: 15 additions & 0 deletions
15
...c/main/java/com/amazon/dataprepper/plugins/sink/opensearch/index/DefaultIndexManager.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
package com.amazon.dataprepper.plugins.sink.opensearch.index; | ||
|
||
import com.amazon.dataprepper.plugins.sink.opensearch.OpenSearchSinkConfiguration; | ||
import com.amazon.dataprepper.plugins.sink.opensearch.index.ismpolicy.NoIsmPolicyManagement; | ||
import org.opensearch.client.RestHighLevelClient; | ||
|
||
public class DefaultIndexManager extends IndexManager { | ||
|
||
public DefaultIndexManager(final RestHighLevelClient restHighLevelClient, | ||
final OpenSearchSinkConfiguration openSearchSinkConfiguration) { | ||
super(restHighLevelClient, openSearchSinkConfiguration); | ||
this.ismPolicyManagementStrategy = new NoIsmPolicyManagement(restHighLevelClient); | ||
} | ||
|
||
} |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Do we still need this level of abstraction? Is the lack of dependecy injection in this project impacting eliminating this?
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.
Yeah, if there is a DI framework like Guice, it may help eliminate children classes. There are other reasons I like have this inheritance:
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 keeping these implementations of
IndexManager
is still important. The OpenSearch plugin defines what each of these types is via an enum which is configured in the pipeline. This strong correspondence between the enum and a known setup for the index lends itself well to these classes (DefaultIndexManager, TraceAnalyticsManager).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.
Let's revist this when we have injection. I believe all of this could be achieved with injection via a map of ENUMs to different implementations of an IndeManger. I believe this is a simplier design and reduces our reliance on inheritence. This does not limit our ability to test the different configuration options nor should it decrease runtime debugging or increase time for users.
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 believe the root problem is that these inherited classes are being exposed. From what I can tell of the code, we should be able to make them private static inner classes of the
IndexManagerFactory
class. At that point, it matters little whether it has its own inherited classes to expose them, or builds them all manually. It is just an implementation detail ofIndexManagerFactory
. I think a quick turnaround PR with this change would be appropriate.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.
Sounds good. Good suggestion, David. I am making the IndexManger
sub-classes private in the factory class. See: #414
I didn't make them static. I have not found being static is necessary.
Please let me know if you have a strong reason to make them static.
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.
They should be static nested classes because they are not tied to the
IndexManagerFactory
class instance itself.From the documentation:
https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html