Difference between revisions of "QUERY"
Line 43: | Line 43: | ||
The correspondence between Queries and its items is created and stored by a relationship (“QUERYRELATION”). Therefore a single QueryItem can be used several times for different Queries. | The correspondence between Queries and its items is created and stored by a relationship (“QUERYRELATION”). Therefore a single QueryItem can be used several times for different Queries. | ||
+ | |||
+ | ==Content queries== | ||
+ | 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 | ||
+ | * derivative from QUERY classified as SYSCLS_QUERY marks instances as content queries | ||
+ | * 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 | ||
+ | * Set filter object (FILTEROBJECT) similar as for other query | ||
+ | * Create a proper relation | ||
+ | * Create a query view item and set the instance as 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 | ||
+ | * 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 (=) | ||
+ | |||
== 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:UBIK Object]] | [[Category:UBIK Object]] |
Revision as of 11:23, 20 June 2013
Query | |
---|---|
Name | QUERY |
Namespace | System.Query |
Internal Name | Query |
TypeString | {{{typestring}}} |
RuntimeType | {{{runtimetype}}} |
Purpose | Configure queries |
Version | 2+ |
Contents
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:
- data fetching (n records)
- finding a single or a set of recordset(s)
- used as definition of root nodes in a View
Query, QueryItem
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
The correspondence between Queries and its items is created and stored by a relationship (“QUERYRELATION”). Therefore a single QueryItem can be used several times for different Queries.
Content queries
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
- derivative from QUERY classified as SYSCLS_QUERY marks instances as content queries
- 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
- Set filter object (FILTEROBJECT) similar as for other query
- Create a proper relation
- Create a query view item and set the instance as 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
- 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 (=)
Usage of DatabaseViews
It is also possible to define a Database View and use this View for the evaluation of Queries (see VirtualContentClass).