[Cubicweb] About RQL language and its correct use

Sylvain Thénault sylvain.thenault at logilab.fr
Tue Apr 27 11:27:36 CEST 2010

On 27 avril 10:45, Julien Jehannet wrote:
> > * Carlos Balderas <carlos.balderas at gmail.com> [26-avr-2010 22:53]:
> > Hello List!
> > 
> > Writting good RQL sentences.
> Good topic :)
> > Is it better to write rql sentence like:
> > ANY X WHERE X is "EntityType", X eid "EID"
> > or just something like this:
> > ANY X WHERE X eid "EID"

1. Unless you can't, eg rql in an url for instance, *always* use
   named argument.
2. We usually don't a type restriction when you have an eid restriction
3. entity types and integers shouldn't be quoted

So the canonical form for your query is:

 execute('Any X WHERE X eid %(x)s', {'x': EID}) 

> > ANY X WHERE X is "EntityType", X in_state Y, Y is State, Y name
> > or just something like this:
> > ANY X WHERE X is "EntityType", X in_state Y, Y name "SOMESTATENAME"
> > or if X is the only entity type that can have "SOMESTATENAME" state
> > ANY X WHERE X in_state Y, Y name "SOMESTATENAME"

in such case, the type restriction may be valuable since it deambiguify
the query and may (depending on other caracteristic of that query) avoid
an UNION on several sql table.

So the canonical form is:

  execute('Any X WHERE X is EntityType, X in_state Y, Y name %(state)s',
          {'state': 'SOMESTATENAME'})

Also, you should add the type restriction if you want to be sure that
you wont get some other entity types when you'll add a new SOMESTATENAME
state for that other entity types.

> The last request could be *huge* because 'name' attribute is widespread
> among entities. For the same reason as above, I will tend to always
> specified the entity type. But in this example, it will be a performance
> boost because the internal generated SQL will only concern a table.

no, because 'X in_state Y' reduces possible types for Y to State entities.

And take care, as I said above, adding the entity type may not be a
performance boost but a penalty.

> > Using "is" sometimes is necesary when we need to filter certain types of
> > entities in rql sentences and this kind of structure sometimes helps the
> > programmer to understand quickly what we are looking for in the rql query,
> > but other times make bigger rql queries and I would like to know if this can
> > help to improve or adversely affect the rql performance in some way.

1. Don't add type restriction for variable with eid specified
2. Add type restriction when your query has to be deambiguified
3. Add type restriction if you really want to filter out other entity types
   that may comes at some point (now or in the future)

Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list