- Created by Robert Reiner, last modified on 07. Apr 2020
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 7 Next »
projectdoc Toolbox
Deep links can be used on both sides of predicates in a Where Clause.
A deep link is an expression where the property value contains an arrow (->) requesting to dereference the property value. Deep links can be used in Select parameters and Where parameters of queries. In a Select parameter the macro simply dereferences the value by following the property chain. Person->Address->City simply renders the value of the City property that is referenced by the Person property via the Address property.
The Where parameter value is a conjunction of predicates. A predicate has two sides. The left side is the name of a property of a document in the result set. This property must match the right side of the predicate: Name=Jane. The left side can contain a reference to the current document, the document that contains the macro with the Where parameter. The syntax is slightly different, since we want to express an exact match: $<Name>=[${Sister->Name}]. Dereferencing the right side is easy, since the right side points to the current document. So this is not different to the task we already solved by using deep links in Selects.
For deep links on the left side of a predicate, the referenced value needs to be materialized. We need to match a document with Lucene and we do not want to dereference a deep link on a collection of possible matches. This might be okay if the number of possible hits is already quite small before we apply the deep link constraints. In case the deep link is the only clue for the query, this would mean that we need to check every document in this way.
In the past materializing properties had to be done manually by adding an additional property to a document at the design time of the document type. So if you would like the birthday of a person in a stakeholder document, where the stakeholder already has a reference to a single person, the additional property on the stakeholder would use the Display Document Property Ref Macro to conjure the person's birthday value to the stakeholder's property (see Materialize Properties for example).
Since version 4.5 materializing is much easier, but is still required in order to use deep links on the left side of the predicate. This tips gives a short overview over deep links on both sides of the predicate.
Queries
Queries define their constraints with the Where parameter, for instance with the Display Table Macro.
For the following examples the Where parameter consists only of a single predicate for simplicity.
Deep Links on the querying Document's Side
The first constraint selects on all documents whose Type property is equal to this document's referenced Service's Type. We expect the value of the Type properties to be single values. Also the Service property is expected to contain no or only one reference to a service document.
$<Type>=[${Service->Type}]
Here is a similar constraint, but this time the property may contain multiple services.
$<Type>~(${Services->Type})
In this case the type must match at least one Type value of the referenced services.
Match List Values with List Operator
In case of multiple values only the list operator (~) will return the desired result.
$<Type>=[${Services->Type}]
Will check for an exact match with the whole list of values. Since the indexer stores each of the list elements individually, the exact match on the list will never be a match.
For instance the Services has the references Service A with a Type value of A and Service B with a Type value of B, then the predicate above will be resolved to
$<Type>=[A, B]
So documents in the result set would require the value A, B as single type value (not the type A and/or B).
In case you actually want to treat a value containing one or more commas as a single value, use the is-single-value control.
Deep Links on the matching Document's Side
To match with deep linked values with the matching document, which is on the left side, the value is required to be materialized.
$<Type->Tags>=[${Tags}]
Again a similar constraint using lists.
$<Categories->Tags>~(${Tags})
For these queries to work, the properties on the left side (Type->Tags respectively Categories->Tags) are required to be materialized.
Materialization can have three forms
| Materialization | Description |
|---|---|
Materialize the controlled property by an artificial property with the given path. | |
Specify which properties to materialize as artificial properties by doctype. | |
Describes the doctypes model. |
Deep Links on both Sides
$<Categories->Tags>=[${Categories->Tags}]
$<Categories->Tags>~(${Categories->Tags})
Resources
- Materialize Properties
- Using existing properties from other documents.
- Display Table Macro
- Lists references to projectdoc documents in a table. Allows to select document properties for columns. Also non-list representations are provided.
- No labels
