Package com.evolveum.midpoint.schema

Interface ResultHandler<T extends ObjectType>

All Superinterfaces:
ObjectHandler<PrismObject<T>>
All Known Implementing Classes:
AbstractSummarizingResultHandler
Functional Interface:
This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.
@FunctionalInterface public interface ResultHandler<T extends ObjectType> extends ObjectHandler<PrismObject<T>>
Classes implementing this interface are used to handle iterative results. It is only used to handle iterative search results now. It may be reused for other purposes as well. Also see ObjectHandler which is not limited to ObjectType and handles real values instead of prism values. TODO this should perhaps be named ObjectResultHandler
Author:
Radovan Semancik

  • Method Summary

    Modifier and Type
    Method
    Description
    default ResultHandler<T>
    providingOwnOperationResult(String operationName)
    Returns the handler with the same functionality as this one, enriching it with providing its own child operation result and taking care of limiting the growth of the operation result tree.

    Methods inherited from interface com.evolveum.midpoint.schema.ObjectHandler

    handle

  • Method Details

    • providingOwnOperationResult

      default ResultHandler<T> providingOwnOperationResult(String operationName)
      Returns the handler with the same functionality as this one, enriching it with providing its own child operation result and taking care of limiting the growth of the operation result tree. The reason is that we need to introduce operation results when *emitting* the objects from the source, in order to distinguish the processing time of handling the objects from the time to produce them. On the *receiving* end, though, we must do the same: we must mark the processing as belonging to the receiving component (like provisioning or model). Said in other words, the receiving side has the primary obligation to provide its own operation result. The emitting side, though, should do this to defend itself if the receiving side doesn't do that. (To ascribe the processing time at least to "handle object found" method of the emitter, so it's discernible there; at least if one looks closely enough.) An exception is when the processing on the receiving size is negligible. This also applies to some intermediaries (like repository cache), which are not the primary processing component. They can safely defer creating the operation result to the upstream processing component(s). (Which can, of course, avoid creating the result if their own processing is small.) However, this exception may not apply when we're crossing the component (repo, provisioning, model, ...) boundaries. At these places, it may make sense to create a separate result even for very small processing. See also the principle #4 in OperationResult javadoc. Open questions: . Do we always need to delete subresults and summarize the parent result? Probably only if we are the first in the chain of handlers, i.e. we create directly the children of the search-like operation result, one related to each object found. . Should the subresult be minor or not? Probably yes.