[Cubicweb] Cubicweb Digest, Vol 14, Issue 10

Carlos Balderas carlos.balderas at gmail.com
Wed Apr 28 05:57:50 CEST 2010


I appreciate your answers, very comprehensive and clear.

Carlos Balderas

On Tue, Apr 27, 2010 at 5:00 AM, <cubicweb-request at lists.cubicweb.org>wrote:

> Send Cubicweb mailing list submissions to
>        cubicweb at lists.cubicweb.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.cubicweb.org/mailman/listinfo/cubicweb
> or, via email, send a message with subject or body 'help' to
>        cubicweb-request at lists.cubicweb.org
>
> You can reach the person managing the list at
>        cubicweb-owner at lists.cubicweb.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cubicweb digest..."
>
>
> Today's Topics:
>
>   1.  Re: About RQL language and its correct use (Julien Jehannet)
>   2. Re: About RQL language and its correct use (Sylvain Th?nault)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 27 Apr 2010 10:45:41 +0200
> From: Julien Jehannet <julien.jehannet at logilab.fr>
> Subject: [Cubicweb]  Re: About RQL language and its correct use
> To: Carlos Balderas <carlos.balderas at gmail.com>
> Cc: cubicweb at lists.cubicweb.org
> Message-ID: <20100427084541.GA7125 at crater.logilab.fr>
> Content-Type: text/plain; charset="utf-8"
>
> > * 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"
>
> In terms of performance, I think the latter could be a bit faster
> but for readibility issue, I will vote for the former.
>
> > ANY X WHERE X is "EntityType", X in_state Y, Y is State, Y name
> > "SOMESTATENAME"
> > 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"
>
> 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.
>
> > 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.
>
> My advice should be to always keep the "is" constraint even if it makes
> the request larger.
>
> Note: I'm not an expert. I'm just sharing that in case if someone could
> correct me if I'm wrong.
> --
> Julien JEHANNET                                          LOGILAB, Paris
> (France)
> http://www.cubicweb.org                 CubicWeb, le cadriciel du web
> s?mantique
> http://www.logilab.org             D?p?t des logiciels libres con?us par
> Logilab
> http://www.logilab.fr       Informatique scientifique & Gestion de
> connaissances
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: Digital signature
> URL: <
> http://lists.cubicweb.org/pipermail/cubicweb/attachments/20100427/d2895e34/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 27 Apr 2010 11:27:36 +0200
> From: Sylvain Th?nault <sylvain.thenault at logilab.fr>
> Subject: Re: [Cubicweb] About RQL language and its correct use
> To: Carlos Balderas <carlos.balderas at gmail.com>,
>        cubicweb at lists.cubicweb.org
> Message-ID: <20100427092736.GC2691 at lupus.logilab.fr>
> Content-Type: text/plain; charset=utf-8
>
> 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
> > > "SOMESTATENAME"
> > > 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 <http://www.logilab.fr/formations%0AD?veloppement> logiciel
> sur mesure:       http://www.logilab.fr/services
> CubicWeb, the semantic web framework:    http://www.cubicweb.org
>
>
>
> ------------------------------
>
> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb
>
>
> End of Cubicweb Digest, Vol 14, Issue 10
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20100427/0127ca47/attachment-0185.html>


More information about the Cubicweb mailing list