Align the Search Service Code Base with OSDU Platform Development Principles.
ADR: Move Code Duplicates from CSP Modules to the Core Module.
Enhance Search service maintenance, align with the future ElasticSearch 8 migration, and minimize the effort needed for introducing Community implementation by reducing code duplication in CSPs modules.
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
The Search service contains duplicated code for constructing Elasticsearch queries within CSP modules, in classes such as QueryBase.java and QueryServiceImpl.java. These redundancies add complexity to code maintenance without offering visible benefits. Query builders do not have CSP-specific code, additionally, differences have emerged in these classes over time:
Decision
Identify delta in search service across different providers. Prioritize the most advanced version if significant differences exist and move it to the Core module. For instance, we previously migrated the optimized geo query builders from the Azure provider to the core: !556 (merged) Following the same principle, we can eliminate other existing duplicates.
Rationale
Aside from the current increased cost and complexity of maintenance, we have at least two major tasks pending in the Search service:
- The migration to ElasticSearch 8 will require migrating all Elasticsearch query builders. Currently, the required effort will increase proportionally with the number of providers. indexer-service#111
- For the Community Implementation of the Search service, selecting a version of Query Builders will be required. It could be a copy of the GC provider, which diverges from OSDU Development principles (like all providers currently), or a robust, reusable solution. https://gitlab.opengroup.org/osdu/pmc/community-implementation/-/issues/9
Consequences
- Removal of code duplicates in provider modules.
- Introduction of a consolidated ElasticSearch query builder in the core module.
- Potential impact on features currently in development due to substantial codebase changes.
Tradeoff Analysis
While this won't break API behavior, it could be seen as disruptive in the development process due to significant codebase changes. Tweaks and improvements made by CSPs to their modules might be overlooked during refactoring if not captured through integration testing.
Alternatives and implications
An alternative to the current ADR involves relocating code duplicates to the Community Implementation module rather than the Core, designated for use in the Community implementation of the Search service. However, this would require developers to support five modules if new features are introduced or if migration to ElasticSearch 8 begins.