[Cubicweb] CWEP-0002 - RQL rewriting

Vincent Michel vincent.michel at logilab.fr
Fri Dec 13 18:07:59 CET 2013


Hi,


On 13/12/2013 17:55, Aurélien Campéas wrote:
> On 13/12/2013 17:47, Vincent Michel wrote:
>> Hi,
>>
>>
>> On 13/12/2013 17:26, Aurélien Campéas wrote:
>>> On 13/12/2013 17:11, Léa Capgen wrote:
>>>> Hi Cubicweb users,
>>>>
>>>> Here is the first hints about allowing users rewriting RQL.
>>>>
>>>> Léa,
>>>>
>>>
>>> Hi Léa,
>>>
>>>>
>>>> Rationale
>>>> ==========
>>>>
>>>>
>>>> Logilab has been thinking about rules and RQL rewriting for years, but
>>>> never had the time. Using rules in database queries is not a new 
>>>> topic,
>>>> that dates back to the 70s (read about Datalog_ for example).
>>>>
>>>> .. _Datalog: http://en.wikipedia.org/wiki/Datalog
>>>>
>>>> With rules and RQL rewriting, we could have syntactic sugar for almost
>>>> free and have more flexible schemas that define relations and 
>>>> attributes
>>>> that we can chose not to materialize at the SQL table level.
>>>>
>>>> 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 
>>>>
>>>>
>>>>
>>>>
>>>> Proposal
>>>> ========
>>>>
>>>> Relation rewriting
>>>> --------------------------
>>>>
>>>> Instead of::
>>>>
>>>>    Any A,B WHERE C is Contribution, C contributor A, C 
>>>> manifestation B,
>>>>                  C role R, R name "illustrator"
>>>>
>>>> we would like to write::
>>>>
>>>>    Any A,B WHERE A illustrator_of B
>>>>
>>>> after adding a rule 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"')
>>>>
>>>>
>>>
>>> So is illustrator_of actually:
>>>
>>> * a pure read-only, not db-backed, kindof "virtual" relation ?
>>>
>>> * a computed relation ?
>>>
>>> * would the (default) primary views of a Person show it ? hide the
>>>   contributions ?
>>>
>>> * what about the edition forms ?
>>>
>>>
>>
>> For now, illustrator_of is a pure read-only "virtual" relation.
>> We want to have two different behaviors in CW:
>>
>>     * pure read-only "virtual" relation, using RQL rewrite and the rule
>> defined in the schema.
>>       This is the mode currently implemented.
>
>
> What does schema['illustrator_of'] yield ?

"illustrator_of" being in the schema as a standard RelationDefinition,
this will be considered as a standard relation from a schema point-of-view.
However, there will be no creation of a relation table in the db.

>
> Do the current implementation garantee that
> the relation won't appear in edition forms ?

No.


>
>>
>>     * "materialized" relation, using a hook to automatically flush
>> information in the database using the rule
>>       defined in the schema. The main idea here is that (using the
>> previous example), modifying/deleting/adding
>>       a "contributor" or "manifestation" relation, will automatically
>> trigger a hook that will insert the "illustrator_of"
>>       relation (if it make sense).
>>       There will be no RQL rewrite, and the rule is only used for hook
>> triggering/relation computation.
>>
>>>>
>>>> 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'))
>>>>
>>>
>>>
>>> I'd ask the exact same questions, plus:
>>>
>>> * what happens if it is actually in the backend and one writes:
>>>   c.cw_set(total_salary=42)  ?
>>
>> This is a current limitation of the Computed Attribute. Similarly to the
>> relation (see "illustrator_of" example), we may want to store the result
>> in the database using a specific hook, or only use RQL rewriting
>> (current implementation).
>
> so schema['total_salary'] raises a KeyError ?
> but then, only hand-written rql can use such an attribute ?
>
> [...]

total_salary is a valid attribute in the schema. The only difference 
between a Computed Attribute and  a standard Attribute is that no column 
will be created (for the implemented version), and each request 
(eventually through the ORM) will be rewritten using the "computed" rule.

>
>
> Regards,
> Aurélien.
>
>

Best,
Vincent

> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb




More information about the Cubicweb mailing list