Offline Query (UBIK WinX)

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).

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.

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.

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.

Ranged criterion for double

Ranged criterion for date time

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 ⩽ ...).

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.

• Offline querying