Difference between revisions of "Offline Query (UBIK WinX)"
| (20 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
Compared to [[QUERY|online / server side queries]], offline queries provide a similar capability to query for objects that match the criteria defined by the query objects. The major differences are: | Compared to [[QUERY|online / server side queries]], offline queries provide a similar capability to query for objects that match the criteria defined by the query objects. The major differences are: | ||
* The querying happens entirely offline without the need of networks; | * The querying happens entirely offline without the need of networks; | ||
| − | * Only | + | * Only objects already available on the client can be found as query results. |
| + | |||
| + | {{Hint|The [[SYSCLS_OFFLINE_QUERY|offline query classification]] is primarily needed on the Scope of the offline query, rather than on the MetaClass itself, because the client evaluates the classification.}} | ||
== Offline query page == | == Offline query page == | ||
| + | [[File:UBIK_WinX_UI_Offline_Query_Page.png|thumb|Offline Query]] | ||
An offline query page looks similar to a regular content page which shows the properties on the left side and the content objects on the right. The unique characteristics of a query page are: | An offline query page looks similar to a regular content page which shows the properties on the left side and the content objects on the right. The unique characteristics of a query page are: | ||
* The properties on the left serve as query criteria; | * The properties on the left serve as query criteria; | ||
| Line 11: | Line 14: | ||
== Offline query criteria == | == Offline query criteria == | ||
| − | An offline query criterion is essentially a property on the query object. When evaluating a query, every criterion/property is checked against all result candidates (See ). A candidate is a match if | + | An offline query criterion is essentially a property on the query object. When evaluating a query, every criterion/property is checked against all result candidates (See [[#Technical_background|technical background]]). A candidate is a match if |
* it has all the same properties as the offline query; | * it has all the same properties as the offline query; | ||
| + | {{Attention|This is changed in newer versions {{Version/WinXSince|3.6}}. A not found property is just ignored.}} | ||
* and the values of these properties indicate they are relevant according to the query criteria. (Some types have different ways to interpret what makes a value relevant. See below.) | * and the values of these properties indicate they are relevant according to the query criteria. (Some types have different ways to interpret what makes a value relevant. See below.) | ||
{{Hint|The value checking of a criterion is ignored during query evaluations under any of the following circumstances. | {{Hint|The value checking of a criterion is ignored during query evaluations under any of the following circumstances. | ||
| Line 27: | Line 31: | ||
| Value Range || || || ✓ || ✓ || ✓ || | | Value Range || || || ✓ || ✓ || ✓ || | ||
|} | |} | ||
| + | |||
| + | {{Attention|Only those criteria/properties for which the MetaProperty.IndexCount is greater than 0 support value ranges.}} | ||
| + | |||
=== Single value criterion === | === Single value criterion === | ||
For most single value criteria, {{UBIK}} considers a candidate as a match if the value of the target property equals the value specified in the criterion. | For most single value criteria, {{UBIK}} considers a candidate as a match if the value of the target property equals the value specified in the criterion. | ||
| Line 34: | Line 41: | ||
For string criteria, instead of checking for the equality, {{UBIK}} does the following. | For string criteria, instead of checking for the equality, {{UBIK}} does the following. | ||
* Split the string value defined in a criterion by spaces ({{Code| }}) if possible; | * Split the string value defined in a criterion by spaces ({{Code| }}) if possible; | ||
| + | <tabs> | ||
| + | <tab name="Since version 3.5"> | ||
| + | * {{Version/WinXSince|3.5}} All of these sub strings must be a part of the string value of the target property in order for the candidate to be a match. | ||
| + | For example, candidate object with a name {{Code|PU112 PD112}} is considered as a match under a name criterion with the value {{Code|PU PD}}, but {{Code|PU112}} is not. | ||
| + | </tab> | ||
| + | <tab name="Older versions"> | ||
* As long as at least one of the sub strings is a part of the string value of the target property, the candidate is a match. | * As long as at least one of the sub strings is a part of the string value of the target property, the candidate is a match. | ||
For example, candidate objects with names {{Code|PU112}} and {{Code|PD2115}} are both considered as matches under a name criterion with the value {{Code|PU PD}}. | For example, candidate objects with names {{Code|PU112}} and {{Code|PD2115}} are both considered as matches under a name criterion with the value {{Code|PU PD}}. | ||
| + | </tab> | ||
| + | </tabs> | ||
| + | <headertabs /> | ||
| + | |||
| + | [[File:UBIK_WinX_UI_Offline_Query_Ranged_Double_Criterion.gif|thumb|Ranged criterion for double]] | ||
| + | [[File:UBIK_WinX_UI_Offline_Query_Ranged_DateTime_Criterion.gif|thumb|Ranged criterion for date time]] | ||
=== Value range criterion === | === Value range criterion === | ||
For types such as numbers or dates, it is sometimes more comfortable to specify ranges for criteria. | For types such as numbers or dates, it is sometimes more comfortable to specify ranges for criteria. | ||
| Line 49: | Line 68: | ||
* inclusive between (... ⩽ value ⩽ ...); | * inclusive between (... ⩽ value ⩽ ...); | ||
* inclusive greater than (value ⩾ ...); | * inclusive greater than (value ⩾ ...); | ||
| − | * inclusive less than (value ⩽ ...). | + | * inclusive less than (value ⩽ ...); |
| + | * in a collection (value is A, B, ... or X, the UI support for this range definition is limited that you can't yet add or remove values in the collection). | ||
== Technical background == | == Technical background == | ||
| − | ... | + | As mentioned earlier, all offline query criteria are checked against the result candidates. The [[SYSCLS_OFFLINE_QUERY|"METACLASS_IDS"]] property of the query object determines which objects are the candidates. |
| + | |||
| + | {{Clear}} | ||
| + | |||
| + | == Query with context filter values {{Version/WinXSince|4.9}}{{Version/XamarinSince|4.9}} == | ||
| + | In some use cases, {{UBIK}} might automatically extract certain values from the so-called context and use them during offline query filtering. The following cases are two typical examples. | ||
| + | * [[Dynamic_Selective_List_(Client)|Dynamic selective list]]. | ||
| + | * [[Data_Replication_(UBIK_Client)#Data_templates|Data template replication]]. | ||
| + | {{Hint|These features worked in earlier versions already. However, the technical design differed and it had certain limitations that made it problematic when you try to evaluate the same query with different filter values at the same time. So the basement, namely offline query with context filter values, is redesigned in the new version.}} | ||
| + | |||
| + | The newly designed version has the following characteristics. | ||
| + | * You can now easily distinguish such automatically extracted context filter values from the user entered filter values in the UI. | ||
| + | * Once there is user entered values, the UI makes it obvious that the user values overrule the context values. | ||
| + | * It's also possible to clear/delete/reset all filter values, whether they are from the context or users. | ||
| + | |||
| + | {{Hint|While it's possible to clear the context filter values, they will be automatically applied again if you start the corresponding filtering process from scratch.}} | ||
| + | |||
| + | {{Attention|By design, the context filter values in the [[Dynamic_Selective_List_(Client)|dynamic selective list]] feature are applied as restrictions. So it is not allowed to overrule those values with user inputs.}} | ||
| + | [[Category:Pages with broken file links|Offline Query (UBIK WinX)]] | ||
[[Category:Version 3.1|Offline Query (UBIK WinX)]] | [[Category:Version 3.1|Offline Query (UBIK WinX)]] | ||
[[Category:WinX|Offline Query (UBIK WinX)]] | [[Category:WinX|Offline Query (UBIK WinX)]] | ||
| + | [[Category:Client|Offline Query (UBIK WinX)]] | ||
| + | [[Category:Xamarin|Offline Query (UBIK WinX)]] | ||
Latest revision as of 11:18, 12 November 2024
Compared to online / server side queries, offline queries provide a similar capability to query for objects that match the criteria defined by the query objects. The major differences are:
- The querying happens entirely offline without the need of networks;
- Only objects already available on the client can be found as query results.
 | The offline query classification is primarily needed on the Scope of the offline query, rather than on the MetaClass itself, because the client evaluates the classification. |
Contents
Offline query page
An offline query page looks similar to a regular content page which shows the properties on the left side and the content objects on the right. The unique characteristics of a query page are:
- The properties on the left serve as query criteria;
- The content objects on the right are the evaluated results of the query;
- There is an additional Evaluate button in the bottom-left corner;
Users can change the query criteria by editing the property values. A press on the Evaluate button then will re-evaluate the query and show the results on the right side.
Offline query criteria
An offline query criterion is essentially a property on the query object. When evaluating a query, every criterion/property is checked against all result candidates (See technical background). A candidate is a match if
- it has all the same properties as the offline query;
- and the values of these properties indicate they are relevant according to the query criteria. (Some types have different ways to interpret what makes a value relevant. See below.)
| The value checking of a criterion is ignored during query evaluations under any of the following circumstances.
|
Several types of criteria are supported on offline queries.
| Boolean | String | Integer | Double | DateTime | Guid | |
|---|---|---|---|---|---|---|
| Single Value | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Value Range | ✓ | ✓ | ✓ |
 | Only those criteria/properties for which the MetaProperty.IndexCount is greater than 0 support value ranges. |
Single value criterion
For most single value criteria, UBIK® considers a candidate as a match if the value of the target property equals the value specified in the criterion.
| It is possible to use a single DateTime value in a query criterion. However, since even the smallest differences (in seconds or even milliseconds) matter during an equality check, you might want to consider specifying a range instead. |
String criterion
For string criteria, instead of checking for the equality, UBIK® does the following.
- Split the string value defined in a criterion by spaces (
Since version 3.5
- All of these sub strings must be a part of the string value of the target property in order for the candidate to be a match.
For example, candidate object with a name PU112 PD112 is considered as a match under a name criterion with the value PU PD, but PU112 is not.
Older versions
- As long as at least one of the sub strings is a part of the string value of the target property, the candidate is a match.
For example, candidate objects with names PU112 and PD2115 are both considered as matches under a name criterion with the value PU PD.
Value range criterion
For types such as numbers or dates, it is sometimes more comfortable to specify ranges for criteria.
- Example 1: Candidate objects with pressure readings
20and25are both considered as matches under a pressure reading criterion with the value20 ⩽ ... ⩽ 25. - Example 2: Candidate objects with start dates
09-11-2017and08-12-2017are both considered as matches under a start date criterion with the value> 08-11-2017.
Currently, the following ranges are supported.
- exclusive between (... < value < ...);
- exclusive greater than (value > ...);
- exclusive less than (value < ...);
- inclusive between (... ⩽ value ⩽ ...);
- inclusive greater than (value ⩾ ...);
- inclusive less than (value ⩽ ...);
- in a collection (value is A, B, ... or X, the UI support for this range definition is limited that you can't yet add or remove values in the collection).
Technical background
As mentioned earlier, all offline query criteria are checked against the result candidates. The "METACLASS_IDS" property of the query object determines which objects are the candidates.
Query with context filter values
In some use cases, UBIK® might automatically extract certain values from the so-called context and use them during offline query filtering. The following cases are two typical examples.
| These features worked in earlier versions already. However, the technical design differed and it had certain limitations that made it problematic when you try to evaluate the same query with different filter values at the same time. So the basement, namely offline query with context filter values, is redesigned in the new version. |
The newly designed version has the following characteristics.
- You can now easily distinguish such automatically extracted context filter values from the user entered filter values in the UI.
- Once there is user entered values, the UI makes it obvious that the user values overrule the context values.
- It's also possible to clear/delete/reset all filter values, whether they are from the context or users.
| While it's possible to clear the context filter values, they will be automatically applied again if you start the corresponding filtering process from scratch. |
| By design, the context filter values in the dynamic selective list feature are applied as restrictions. So it is not allowed to overrule those values with user inputs. |
