Separate concerns in the ReadOperation

[ivansenic]

Currently the ReadOperation serves as a base class for FindOperation and CountOperation. However, the count operation does not implement any of the abstract methods:

  @Override
  public Uni<FindResponse> getDocuments(QueryExecutor queryExecutor, String pagingState) {
    return Uni.createFrom().failure(new JsonApiException(ErrorCode.UNSUPPORTED_OPERATION));
  }

  @Override
  public ReadDocument getNewDocument() {
    throw new JsonApiException(ErrorCode.UNSUPPORTED_OPERATION);
  }

In addition the count related method countDocuments is used only by the CountOperation, thus is not needed at all in the base interface. This all looks like a bad design.

Tasks:

• Count operation does not need to extend the read operation
  • Move count related method to the count operation
• Same can be done for Find operation, effectivelly leaving Read operation as empty interface
• In order for this to work the FilterableResolver class should be transitioned to FilterableResolverService and resolver can directly use this service to resolve the filter clause

@amorton @amorton Please review and approve issue.

[maheshrajamani]

Imo changing the FilterableResolver as FilterableResolverService is not required.
Easier refactoring for the 2 methods, would be to add default implementation to return Unsupported_Operation exception in ReadOperation interface and remove it from CountOperation class. Even if any new implementation for this interface will be taken care of.

[ivansenic]

We should never throw UnsupportedOperationException, it's the first sign of a bad design.