[Cubicweb] ORMHelper registry
sylvain.thenault at logilab.fr
Wed Mar 9 08:57:37 CET 2011
On 09 mars 08:30, Adrien Di Mascio wrote:
> On 08/03/2011 20:38, aurélien campéas wrote:
> > - use RQL functions to change fetch_order
> >this is not (yet) very palatable to me
> >any example ?
> RQL functions is actually a not-so-good example since this is
> already achievable with a custom fetch_order method as in:
> def fetch_order(cls, attr, var):
> if attr == 'firstname':
> return 'LOWER(firstname)'
> return None
> but then what if the RQL function takes 2 parameters ? One being the
> corresponding attribute, the other being another attribute or worse
> an attribute fetched on a linked entity (typically a linked by a
> composite relation).
I ask you the question : then what?
> We could simply extend ``fetch_order()`` (and ``fetch_attrs()``) API
> and expose the rql syntax tree there, but I think a more general
> approach is to consider that we can't foresee every cases and the
> ``ORMHelper`` (or DatabaseHelper or whatever it would be called)
> would solve this case.
> Another benefit I can see is that it will unclutter a bit the Entity
> class and provide a better dispatch of responsibilities, and I
> really think there are cases where fetch_attrs should be
IMO there are two different things:
* moving api to control order and fetched attributes away from entity,
and into an adapter to make this easily overridable per entity (and more,
such as relation being traversed as you told earlier)
* extending this api to allow more control
Each point being desirable :)
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