Jump to: navigation, search

Difference between revisions of "QUERY"


(Lazy loading query)
 
(31 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{MetaClassInfoBox
 
{{MetaClassInfoBox
 
| title = Query
 
| title = Query
| name = QUERY
+
| name = {{PAGENAME}}
| internalname = Query
+
| internalname = SystemObjects.{{PAGENAME}}
| namespace = System.Query<br/>Custom.Query
+
| namespace = System.Query
 
| image = [[File:SY_QUERY.png|220px]]
 
| image = [[File:SY_QUERY.png|220px]]
 
| imagecaption = Query
 
| imagecaption = Query
 
| purpose = Configure queries
 
| purpose = Configure queries
 
| version = 2+
 
| version = 2+
 +
| typestring = UBIK.Kernel.MetaClass
 +
| runtimetype = UBIK.Kernel.Query
 
}}
 
}}
 
+
In UBIK, queries are used for fetching a list of [[ContentClass|ContentClasses]] from the database. Queries use data base mechanism for perfomant data access and will deliver a list of objects of a certain [[Metaclass]].
{{HintMethods}}
+
 
+
== Basics ==
+
In UBIK, queries are used for fetching a list of [[Contentclass|ContentClasses]] from the database. Queries use data base mechanism for perfomant data access and will deliver a list of objects of a certain [[Metaclass]].
+
 
Queries can be used in different scenarios:  
 
Queries can be used in different scenarios:  
 
* data fetching (n records)
 
* data fetching (n records)
Line 19: Line 17:
 
* used as definition of root nodes in a [[View]]
 
* used as definition of root nodes in a [[View]]
  
== Query, QueryItem ==
+
{{HintMethods}}
A Query is defined for a single MetaClass. The MetaClass is defined by a Referenceproperty ''FILTEROBJECT''. A Query will deliver ContentClasses(instances) of the defined MetaClass.
+
A Query holds a list of QueryItems. A single QueryItem defines a single filter rule for the evaluation of the result collection:
+
* OPERATOR
+
e.g. “=”
+
* LIKECOMPARISON
+
is the given item a “LIKE” filter criteria (wildcard is added to the filtervalue)
+
* FILTERVALUE
+
the value the objects are compared to
+
* ISNULL
+
searched for NULL values
+
* LOGICALAND
+
is there a logical AND relation between the given QueryItem and its predecessor (TRUE) or an OR relation (false)
+
  
== Relation between Query and Items ==
+
== Query and QueryItems ==
The correspondence between Queries and its items is created and stored by a relationship [[SYSREL_QUERYRELATION]]. Therefore a single QueryItem can be used several times for different Queries.
+
A Query is defined for a single [[MetaClass]], where the MetaClass is defined in the property '''FILTEROBJECT'''. Once a query is evaluated it will deliver a list of objects of type ContentClasses (instances), filtered as defined by its [[QUERYITEM|QueryItems]].
 +
The correspondence between Queries and its items is created and stored by a relationship [[SYSREL_QUERY]]. Therefore a single QueryItem can be used several times for different Queries.
  
==Content queries==
+
The "FILTEROBJECT" of a query describes the target MetaClass to find instances of. E.g., if I want to find pumps, a MetaClass "MC_PUMP" can be used as filter target. The query items of a query describe filters for property values. E.g., a query item could specify that only objects with a value larger than "12" in the "VOLTAGE" MetaProperty should be retrieved. Multiple query items can be connected logically (AND/OR) so all of them or just some (or one) of them need to match.
We often face the need to fetch a list of objects meeting arbitary criteria, for example for
+
* scanning of ID markers (QR-Code, Barcode, …)
+
* show objects from deeper hierarchy levels
+
  
Storing of data permanently on the device would need too much resources, hence we load the objects from server on demand. Characteristics of a content query are
+
==Content query ==
* derivative from QUERY classified as SYSCLS_QUERY marks instances as content queries
+
Objects can be loaded on demand from the server, as storing a huge amount of data permanently on the device would need too much resources. A content query is a Query instance classified as [[SYSCLS_QUERY]] and can be related to other content objects. For being shown in the View hierarchy it is necessary to [[HowTo:Create_a_new_ViewItem#QueryViewItem|create a QueryViewItem]] for the query object itself. Further on, for being published to the client a [[QUERYSCOPE|Query Scopes]] has to be [[HowTo:Create_a_new_QueryScope|created]] and added to the [[ACM]].
* Related to instances via relations
+
* Placed in view hierarchy defined via view items
+
* Require context scopes on client side
+
  
Configuration of a content query requies
+
The result of the query depends on the network connection and the {{UBIK}} [[Sync Mode|sync mode]] and follows the same rules as [[Optical_code#Searching_for_objects|Searching for objects by Optical codes]].
* Set filter object (FILTEROBJECT) similar as for other query
+
 
* Create a proper relation
+
== Scan query ==
* Create a query view item and set the instance as QUERY
+
Objects can be searched by optical codes (e.g. Barcode, QR code) using a scan query.
* Create a relation view item and set the according default MetaClass and relation
+
 
* Create and relate a query context scope and set the instance as QUERY
+
See detailed articles on [[HowTo:Make_an_Object_be_found_by_Optical_Codes|How to prepare the object]] and [[HowTo:Find_Objects_by_Optical_Codes|How to find objects on the client]].
* For the scope define the MetaProperties, which should be available as filter criteria on the client. Without appropriate query item, equality is used as filter operator (=)
+
 
 +
== Lazy loading query ==
 +
{{Version/WinXSince|4.4.0}} {{Version/XamarinSince|4.4.0}}
 +
 
 +
The evaluation of a [[SYSCLS LAZY LOADING QUERY|lazy loading Query's]] children is done automatically if no local children exist yet, otherwise evaluation has to be triggered manually to prevent excessive server calls. In the case of an [[Offline_Query_(UBIK_WinX)|Offline Query]] the evaluation happens despite the existence of local children.
 +
 
 +
[[Category:Metaclasses|QUERY]]
  
 
== Usage of DatabaseViews ==
 
== Usage of DatabaseViews ==
 
It is also possible to define a Database View and use this View for the evaluation of Queries (see [[VirtualContentClass]]).
 
It is also possible to define a Database View and use this View for the evaluation of Queries (see [[VirtualContentClass]]).
  
[[Category:Metaclasses]]
+
== See also ==
 +
* [[QUERYITEM]]
 +
 
 +
[[Category:Metaclasses|QUERY]]

Latest revision as of 10:00, 3 May 2023

IC METACLASS.gif Query
Name QUERY
Namespace System.Query
Internal Name SystemObjects.QUERY
TypeString UBIK.Kernel.MetaClass
RuntimeType UBIK.Kernel.Query
Purpose Configure queries
Version 2+

In UBIK, queries are used for fetching a list of ContentClasses from the database. Queries use data base mechanism for perfomant data access and will deliver a list of objects of a certain Metaclass. Queries can be used in different scenarios:

  • data fetching (n records)
  • finding a single or a set of recordset(s)
  • used as definition of root nodes in a View
IC Hint square.pngThere are specific methods available for this type!

Query and QueryItems

A Query is defined for a single MetaClass, where the MetaClass is defined in the property FILTEROBJECT. Once a query is evaluated it will deliver a list of objects of type ContentClasses (instances), filtered as defined by its QueryItems. The correspondence between Queries and its items is created and stored by a relationship SYSREL QUERY. Therefore a single QueryItem can be used several times for different Queries.

The "FILTEROBJECT" of a query describes the target MetaClass to find instances of. E.g., if I want to find pumps, a MetaClass "MC_PUMP" can be used as filter target. The query items of a query describe filters for property values. E.g., a query item could specify that only objects with a value larger than "12" in the "VOLTAGE" MetaProperty should be retrieved. Multiple query items can be connected logically (AND/OR) so all of them or just some (or one) of them need to match.

Content query

Objects can be loaded on demand from the server, as storing a huge amount of data permanently on the device would need too much resources. A content query is a Query instance classified as SYSCLS QUERY and can be related to other content objects. For being shown in the View hierarchy it is necessary to create a QueryViewItem for the query object itself. Further on, for being published to the client a Query Scopes has to be created and added to the ACM.

The result of the query depends on the network connection and the UBIK® sync mode and follows the same rules as Searching for objects by Optical codes.

Scan query

Objects can be searched by optical codes (e.g. Barcode, QR code) using a scan query.

See detailed articles on How to prepare the object and How to find objects on the client.

Lazy loading query

The evaluation of a lazy loading Query's children is done automatically if no local children exist yet, otherwise evaluation has to be triggered manually to prevent excessive server calls. In the case of an Offline Query the evaluation happens despite the existence of local children.

Usage of DatabaseViews

It is also possible to define a Database View and use this View for the evaluation of Queries (see VirtualContentClass).

See also