|all definitions||discriminator||Item whose values will used to segment objects into buckets (if applicable). Usually required.|
|matchingRule||Matching rule to be applied when creating filters (if applicable). Optional.|
|numberOfBuckets||Number of buckets to be created (if applicable). Optional.|
|numericSegmentation||from||Start of the processing space (inclusive). If omitted, 0 is assumed.|
End of the processing space (exclusive). If not present, both
Size of one bucket. If not present it is computed as the total processing space divided by number of buckets (i.e.
Characters that make up the prefix or interval. Currently, the string segmentation is done by creating all possible boundaries (by combining
This is a multivalued property: the first value contains characters that occupy the first place in the boundary. The second value contains characters destined for the second place, etc.
An example: if
Another example: if
Beware: current implementation requires that the characters are specified in the order that complies with the matching rule used. Otherwise, empty intervals might be generated, like when using "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" there will be an interval of e.g. "values greater than
If a value
|oidSegmentation||The same as stringSegmentation but providing defaults of |
|explicitSegmentation||content||Explicit content of work buckets to be used. This is useful e.g. when dealing with filter-based buckets. But any other bucket content (e.g. numeric intervals, string intervals, string prefixes) might be used here as well.|
oidSegmentation is the easiest one to be used when dealing with repository objects. The following creates 162 = 256 segments.
<workManagement> <buckets> <oidSegmentation> <depth>2</depth> </oidSegmentation> </buckets> </workManagement>