Translate
We need to be able to search our content by an attribute value, in this specific case by the ishcondition value. Is this possible in KC?
We need to be able to search our content by an attribute value, in this specific case by the ishcondition value. Is this possible in KC?
Thanks for all the contributions 'CMS Adminstrator2', the right route for this would be the ideas section community.sdl.com/.../tridion-docs-ideas
I assume you already found this, for other SDL documented some of these enhanced searches on https://docs.sdl.com/796504/731092/sdl-tridion-docs-14-sp2/search-for-content
Slightly more technical, you could see xml as a tree structure where every element is a branch and the text inside the elements is ending up as leaves. This is something a full-text-index like Solr or Elasticsearch is not good at, they like flat text - or flat text in fields (e.g. title or shortdesc) at best, but nothing hierarchical.
In turn @ishcondition typically holds a tree structure as well because of the boolean logic (in you example, audience is a branch and management_platform is a branch joined together by an AND). To connect the best of both worlds, we denormalize a lot of those tree structures, so if I remember correctly you are able to find ishcondition="audience=advanced" AND ishcondition="Management_Platform=ePolicy Orchestrator" A full text search however doesn't know how close these search terms are together in the text and will give you some false positives as well.
In 'Condition Manager' tool, we use the object metadata. The CMS stores the atomic condition-name:condition-value combinations (without any operators) which are used inside the xml. More accurate as it comes from the relational database, but way slower than the full-text-index. This is all about balancing accuracy with performance.
I assume you already found this, for other SDL documented some of these enhanced searches on https://docs.sdl.com/796504/731092/sdl-tridion-docs-14-sp2/search-for-content
Slightly more technical, you could see xml as a tree structure where every element is a branch and the text inside the elements is ending up as leaves. This is something a full-text-index like Solr or Elasticsearch is not good at, they like flat text - or flat text in fields (e.g. title or shortdesc) at best, but nothing hierarchical.
In turn @ishcondition typically holds a tree structure as well because of the boolean logic (in you example, audience is a branch and management_platform is a branch joined together by an AND). To connect the best of both worlds, we denormalize a lot of those tree structures, so if I remember correctly you are able to find ishcondition="audience=advanced" AND ishcondition="Management_Platform=ePolicy Orchestrator" A full text search however doesn't know how close these search terms are together in the text and will give you some false positives as well.
In 'Condition Manager' tool, we use the object metadata. The CMS stores the atomic condition-name:condition-value combinations (without any operators) which are used inside the xml. More accurate as it comes from the relational database, but way slower than the full-text-index. This is all about balancing accuracy with performance.