[Cubicweb] CWEP-0002 - RQL rewriting

Florent Cayré florent.cayre at logilab.fr
Sun Dec 15 14:05:51 CET 2013


Le 13/12/2013 18:07, Vincent Michel a écrit :
> 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.

Couldn't we disallow __permissions__ to be setup on such relations (and 
computed attributes), and automatically set permissions to read-only 
values? This is probably easily implemented and should solve the edition 
issue IMHO.

>
>
>>
>>>
>>>     * "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
>
> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb




More information about the Cubicweb mailing list