Skip to content

NIFI-10752: Implement GetCouchbase and PutCouchbase processors with SDK3 #10031

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mark-bathori
Copy link
Contributor

@mark-bathori mark-bathori commented Jun 20, 2025

Summary

This PR introduces an architectural pattern similar to the Kafka bundle. Its main idea is to decouple top-level Couchbase processors and services from specific SDK dependencies. This is achieved by introducing a Controller Service layer that directly implements the service API methods based on a selected SDK. The advantage of this approach is that if a new Couchbase SDK is released, we avoid duplicating existing top-level processors and services. Instead, a new service bundle can be created to implement the new SDK, and components can simply be reconfigured to use the updated service.

NIFI-10752

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Pull Request Tracking

  • Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
  • Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

  • Pull Request based on current revision of the main branch
  • Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

  • Build completed using mvn clean install -P contrib-check
    • JDK 21

Licensing

  • New dependencies are compatible with the Apache License 2.0 according to the License Policy
  • New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

  • Documentation formatting appears as expected in rendered files

Copy link
Contributor

@exceptionfactory exceptionfactory left a comment

Choose a reason for hiding this comment

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

Thanks for putting together new support for Couchbase @mark-bathori!

I noted a couple initial recommendations, and I would like to take a closer look soon.

One other general note, did you consider creating an integration test using Testcontainers? That could be very useful for verifying behavior against a running instance of Couchbase.


public interface CouchbaseConnectionService extends ControllerService {

PropertyDescriptor COUCHBASE_CLUSTER_SERVICE = new PropertyDescriptor.Builder()
Copy link
Contributor

Choose a reason for hiding this comment

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

Including Property Descriptors in a service interface definition is generally poor practice, because it is not part of the Controller Service contract. I recommend removing this Descriptor from the interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes it doesn't seem right to put a Property Descriptors into this interface, the implementations will need to use a cluster service and somehow I wanted to avoid the duplication, will rework this.

}

public enum ErrorHandlingStrategy {
Rollback, Failure, Retry
Copy link
Contributor

Choose a reason for hiding this comment

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

In general, enum values should be uppercased. Is there a reason for this naming convention?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They should be uppercase, I'll fix them.


import static org.apache.nifi.services.couchbase.exception.CouchbaseErrorHandler.ErrorHandlingStrategy.Failure;

public class CouchbaseErrorHandler {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason for including this class in the API module? It seems like it should be located in one of the implementation modules, or in a shared module if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea here is to create a common class for error handling. SDK-specific implementations will then determine which exceptions are considered fatal, recoverable, or other categories by adding the proper mapping to this class. Based on that, it felt like the proper place for this class was alongside other classes used in the API interfaces.

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