Difference between revisions of "Offline Query (UBIK WinX)"

Revision as of 08:44, 9 November 2017

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 local objects can be found as query results (for obvious reasons).

Offline query page

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:

• 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. The criterion does not have any value specified; The criterion type is not supported/unknown. (See below)

Several types of criteria are supported on offline queries.

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 ( ) if possible;
• 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 20 and 25 are both considered as matches under a pressure reading criterion with the value 20 ⩽ ... ⩽ 25.
• Example 2: Candidate objects with start dates 09-11-2017 and 08-12-2017 are 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 ⩽ ...).

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.