Constraint, condition and repeat elements (queries) on shared elements have a mysterious "shared?" checkbox.
Short Answer: Check the "shared" box for big performance improvements! Version 2.00.05 checks the "shared" box by default.
Why?
If this checkbox is checked, the query works in a global way - like it did in 1.15.x. This means that all selections of the shared entry are counted towards the query, no matter the parent - i.e. all links to the entry count.
If left unchecked, the query works on a per entry basis, like a normal entry. This means only selections of this instance of the entry are counted towards the query, and the parent matters - i.e. only links to this entry on a particular parent entry count.
Consider:
|- Shared Selection Entries
|- S
|- Constraint: Max 1 in Roster
|- Selection Entries
|- A
|- Link to S
|- B
|- Link to S
1) The user selects one of both A and B in their roster, and selects S for both of them.
- If the constraint has "shared" checked, this will give an error. The constraint is "max 1 S in roster". The user has selected two of S, which violates the constraint.
- If the constraint does _not_ have "shared" checked, no error will be given. The constraints are "max 1 A->S in roster" and "max 1 B->S in roster". The user has selected one of A->S and one of B->S, which does not violate the constraint.
2) The user selects two of A in their roster and selects S for both of them.
- If the constraint has "shared" checked, this will give an error, like before. The constraint is "max 1 S in roster". The user has selected two of S, which violates the constraint.
- If the constraint does _not_ have "shared" checked, _an error will still be given_. The constraints are "max 1 A->S in roster" and "max 1 B->S in roster". The user has selected two of A->S, which violates the constraint.
This gives greater power over how you want a query to work. But great power = great responsibility blah blah.
Leaving the "shared" box unchecked means that the app must check the condition multiple times (for each parent) when validating for error messages. Each linked copy of the shared item must be checked.
Checking the "shared" box is much much faster, as the app only needs to check once, globally, that the condition is met/broken.
So check the box unless you have a good reason not to.
Version 2.00.05 (desktop) now checks this box by default.
Constraint, condition and repeat elements (queries) on shared elements have a mysterious "shared?" checkbox.
Short Answer: Check the "shared" box for big performance improvements! Version 2.00.05 checks the "shared" box by default.
Why?
If this checkbox is checked, the query works in a global way - like it did in 1.15.x. This means that all selections of the shared entry are counted towards the query, no matter the parent - i.e. all links to the entry count.
If left unchecked, the query works on a per entry basis, like a normal entry. This means only selections of this instance of the entry are counted towards the query, and the parent matters - i.e. only links to this entry on a particular parent entry count.
Consider:
1) The user selects one of both A and B in their roster, and selects S for both of them.
2) The user selects two of A in their roster and selects S for both of them.
This gives greater power over how you want a query to work. But great power = great responsibility blah blah.
Leaving the "shared" box unchecked means that the app must check the condition multiple times (for each parent) when validating for error messages. Each linked copy of the shared item must be checked.
Checking the "shared" box is much much faster, as the app only needs to check once, globally, that the condition is met/broken.
So check the box unless you have a good reason not to.
Version 2.00.05 (desktop) now checks this box by default.