[Cubicweb] CWEP-0002 - RQL rewriting

Sylvain Thénault sylvain.thenault at logilab.fr
Fri Dec 20 09:41:31 CET 2013


On 18 décembre 15:18, Léa Capgen wrote:
> Here are a few examples of use cases. A more complete document can
> be found here:
> 
> http://hg.logilab.org/users/lcapgen/cw_rules/file/44522d5906d4/cw-regles-utilisations.rst

  An error occurred while processing your request:

  revision not found: 44522d5906d413453860a6275ebded18d2c48dad
 
Also, the CWEP is the complete document, interesting use-cases should go there.

> Computed attribute
> ..........................
> 
> Instead of::
> 
>   Any SUM(SA) GROUPBY S WHERE P works_for S, P salary SA
> 
> we would like to write::
> 
>   Any A WHERE S total_salary A
> 
> after adding to the schema a rule for the computed attribute as follows:
> 
> .. sourcecode:: python
> 
>     class Company(EntityType):
>         name = String()
>         total_salary = Int(computed=('Any SUM(SA) GROUPBY S WHERE P
> works_for S, P salary SA'))
 
It's time to decide if we want S or X here. My vote goes for X.

> Further use cases
> ----------------------
> 
> Map RDF to Yams
> ...................
> 
> Given the following XY equivalences:
> 
> .. sourcecode:: python
> 
>    xy.add_equivalence('CWUser', 'foaf:Person')
>    xy.add_equivalence('Person', 'foaf:Person')
> 
> when writing::
> 
>     Any S WHERE S is foaf:Person
> 
> we would like the query to be rewritten as::
> 
>     Any A WHERE A is IN(Person, User)

As already said, I'ld remove that from this document which is about having way
to define "computed" relation/attribute.
 
> Choice of materializing at the SQL table level
> -----------------------------------------------
> Relation rewriting
> ....................
> 
> The default behavior for relation rewriting implies that the
> matching SQL tables are not materialized. Each time a request uses
> the relation, it rewrites it.
> If one wants to materialized the relation at the SQL table level,
> one has to add an annotations to the schema as follows:
> 
> .. sourcecode:: python
> 
>     class illustrator_of(RelationDefinition):
>         subject = 'Person'
>         object = 'Manifestation'
>         rule  = ('C is Contribution, C contributor S, C manifestation O,'
>                  'C role R, R name "illustrator"')
>         __annotations__ = {'materialized' : True}
> 
> SQL tables will be created and filled with a hook using the rule.

Here I would explain:
* the concept of (non)materialization for relation
* what's happen for materialized computed relation
* what's happen for non-materialized computed relation
* the default behaviour you propose and the reason for it

One thing this CWEP has to precise is the RelationType / RelationDefinition:
* what goes on RelationType (eg materialized)
* what goes on RelationDefinition (may we have different rule for different
  relation def?)

Also, in the materialized case, shall we support inlined=True?

> Computed attribute rewriting
> .............................
> 
> The default behavior for a computed attribute rewriting implies that
> the matching SQL tables are materialized. SQL tables will be created
> and filled with a hook using the computed rule.
> If one wants not to materialized the relation at the SQL table
> level, one has to add an annotations to the computed attribute as
> follows:

Be precise: for attributes we're talking about a column in the entity's table.

Also, same thing as for relation:
* the concept of (non)materialization for attribute
* what's happen for materialized computed attribute
* what's happen for non-materialized computed attribute
* the default behaviour you propose and the reason for it

> .. sourcecode:: python
> 
>     class Company(EntityType):
>         name = String()
>         total_salary = Int(computed=('Any SUM(SA) GROUPBY S WHERE P
> works_for S, P salary SA'),
>                             __annotations__ = {'virtual' : True})
> 
> Each time a request uses the computed attribute, it rewrites it.

I'm still -1 on a different annotation for materializing. You should at least
tell this is contreversial and why you think this choice is better.

Last but not least, here are the things still missing from this document:

* the part of the API visible from the yams schema POV (ie. rdef.rule for
  relation / rdef.computed for attribute?)

* how should it behave in default primary view and edit form?

* how should it behave wrt write queries?

* start thinking about migration of all that (eg what if the rule for a relation
  change from a version to another)

> Limitations for relation rewriting
> ..........................................
> 
> + The rules are written in a dictionnary like {premisse :
> conclusions}. The premisse is a unique relation.
 
I don't get this point. This seems very internal stuff, is it necessary for this
document. Also dictionary has a single 'n' :)

> Materializing formalism
> ------------------------
> 
> What is existed now
> ....................
> For the moment, we have two __annotations__:
>     + __annotations__ = {'materialized' : True} to force rewritten
> relation to be materialized at SQL table level
>     + __annotations__ = {'virtual' : True} to force computed
> attribute to not be materialized at SQL table level
> 
> Our possible choices
> .....................
> 1) We prefer the consistency of the formalism:
>     - In this case, we have to choice between __annotations__ =
> {'materialized' : True} and __annotations__ = {'virtual' : True}.
>     - It implies that relation and computed attribute have **the
> same default behavior**.
> 
> 2) We consider CA and relation have distinct behavior:
>     - It is what is existed now

this should go with the part introducing this.

-- 
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
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