2.1. Introduction — CubicWeb 3.13.2

### Navigation

- index
- modules |
- next |
- previous |
- CubicWeb 3.13.2 »
- Appendixes »
- 2. Relation Query Language (RQL) »

# 2.1. Introduction

## 2.1.1. Goals of RQL

The goal is to have a semantic language in order to:

- query relations in a clear syntax
- empowers access to data repository manipulation
- making attributes/relations browsing easy

As such, attributes will be regarded as cases of special relations (in terms of usage, the user should see no syntactic difference between an attribute and a relation).

## 2.1.2. Comparison with existing languages

### 2.1.2.1. SQL

RQL may remind of SQL but works at a higher abstraction level (the CubicWeb framework generates SQL from RQL to fetch data from relation databases). RQL is focused on browsing relations. The user needs only to know about the CubicWeb data model he is querying, but not about the underlying SQL model.

### 2.1.2.2. Sparql

The query language most similar to RQL is SPARQL, defined by the W3C to serve for the semantic web.

### 2.1.2.3. Versa

We should look in more detail, but here are already some ideas for the moment ... Versa is the language most similar to what we wanted to do, but the model underlying data being RDF, there are some things such as namespaces or handling of the RDF types which does not interest us. On the functionality level, Versa is very comprehensive including through many functions of conversion and basic types manipulation, which we may want to look at one time or another. Finally, the syntax is a little esoteric.

### 2.1.2.4. Datalog

Datalog is a prolog derived query langage which applies to relational databases. It is more expressive than RQL in that it accepts either extensional and intensional predicates (or relations). As of now, RQL only deals with intensional relations.

## 2.1.3. The different types of queries

Search (Any)
  Extract entities and attributes of entities.
Insert entities (INSERT)
  Insert new entities or relations in the database. It can also directly create relationships for the newly created entities.
Update entities, create relations (SET)
  Update existing entities in the database, or create relations between existing entities.
Delete entities or relationship (DELETE)
  Remove entities or relations existing in the database.

## 2.1.4. RQL relation expressions

RQL expressions apply to a live database defined by a Yams schema. Apart from the main type, or head, of the expression (search, insert, etc.) the most common constituent of an RQL expression is a (set of) relation expression(s).

An RQL relation expression contains three components:

- the subject, which is an entity type
- the predicate, which is a relation definition (an arc of the schema)
- the object, which is either an attribute or a relation to another entity

Warning

A relation is always expressed in the order: `subject`, `predicate`, `object`.

It is important to determine if the entity type is subject or object to construct a valid expression. Inverting the subject/object is an error since the relation cannot be found in the schema.

If one does not have access to the code, one can find the order by looking at the schema image in manager views (the subject is located at the beginning of the arrow).

An example of two related relation expressions:

    P works_for C, P name N

RQL variables represent typed entities. The type of entities is either automatically inferred (by looking at the possible relation definitions, see Relation definition) or explicitely constrained using the `is` meta relation.

In the example above, we barely need to look at the schema. If variable names (in the RQL expression) and relation type names (in the schema) are expresssively designed, the human reader can infer as much as the CubicWeb querier.

The `P` variable is used twice but it always represent the same set of entities. Hence `P works_for C` and `P name N` must be compatible in the sense that all the Ps (which can refer to different entity types) must accept the `works_for` and `name` relation types. This does restrict the set of possible values of P.

Adding another relation expression:

    P works_for C, P name N, C name "logilab"

This further restricts the possible values of P through an indirect constraint on the possible values of `C`. The RQL-level unification happening there is translated to one (or several) joins at the database level.

Note

In CubicWeb, the term relation is often found without ambiguity instead of predicate. This predicate is also known as the property of the triple in RDF concepts

## 2.1.5. RQL Operators

An RQL expression’s head can be completed using various operators such as `ORDERBY`, `GROUPBY`, `HAVING`, `LIMIT` etc.

RQL relation expressions can be grouped with `UNION` or `WITH`. Predicate oriented keywords such as `EXISTS`, `OR`, `NOT` are available.

The complete zoo of RQL operators is described extensively in the following chapter (RQL syntax).

### Navigation

- index
- modules |
- next |
- previous |
- CubicWeb 3.13.2 »
- Appendixes »
- 2. Relation Query Language (RQL) »