Enable users to control collections during merging about smart-mastering-core HOT 5 CLOSED

Proposal: allow a collectionStrategy entry under the algorithms part of merge config:

{
  "options:" {
    "algorithms": {
      "collectionStrategy": {
        "function": "myCollectionBuilder",
        "at": "/some/dir/myCode.sjs"
      }
    }
  }
}

The collection strategy function could get an object (SJS) or map (XQuery) where the keys are the URIs of the source document and the values are the collections that each source document is in. The function would return an array (SJS) or sequence (XQuery) of strings with the names of the collections to add to the new document. The default strategy (as happens now) would be the union of source document collections plus $const:MERGED-COLL.

Matching already allows callers to specify a filter-query to narrow down what documents should be considered for matching. I think you're also saying we should just rely on the filter query and forget the requirement that docs be in the $const:CONTENT-COLL. Correct?

from smart-mastering-core.

Should allow the collection strategy to control the collections when archiving, too. Currently when merging, all source docs get put into the $const:ARCHIVED-COLL.

from smart-mastering-core.

Configuration will control the collections that get applied to documents at various times. Configuration will be part of the merge options.

  <algorithms xmlns="http://marklogic.com/smart-mastering/merging">
    <collections>
      <on-merge function="union" at="/some/dir/code.xqy" ns="some-namespace"/>
      <on-archive function="remove-content-coll" at="/some/dir/code.xqy" ns="some-namespace"/>
      <on-no-match function="add-content-coll" at="/some/dir/code.xqy" ns="some-namespace"/>
      <on-notification function="add-notification-coll" at="/some/dir/code.xqy" ns="some-namespace"/>
    </collections>
  </algorithms>

The on-merge strategy will determine what collections are applied to newly created merged documents. Default strategy: union of all collections on source documents, plus $const:CONTENT-COLL. Comment if there's interest in having an intersection plus $const:CONTENT-COLL strategy available out of the box.

The on-archive strategy will determine what collections are applied to documents that get archived (merged into other documents). Default strategy: add $const:ARCHIVED-COLL, remove $const:CONTENT-COLL.

The on-no-match strategy will determine what collections are applied to documents passed to process:process-match-and-merge but do find any matches. Default strategy: no change to the document's collections. There will be an out of the box strategy to add the $const:CONTENT-COLL collection.

The on-notification strategy will determine what collections are applied to newly created notification documents. Default strategy: notification documents will get the $const:NOTIFICATION-COLL collection.

For each type of content strategy, we'll define an API that can be used to make custom strategies.

from smart-mastering-core.

To restate: The goal is for users to write merge algorithms/logic for metadata, including collections. Correct?

from smart-mastering-core.

this story covers collections, there's another one for permissions, but yeah, that's the idea

from smart-mastering-core.