cubicweb #1079123 Have a fetch_attr like feature for RQL requests [open]
The fetch_attr feature of the ORM is very interesting to optimize the number of queries performed within a single web request, and should be extended to plain RQL requests; a syntax similar to something like this would be great
self._cw.execute('Any U,C WHERE C is Comment, C owned_by U', complete=('U', 'C'))
This would use CWUser and Comment fetch_attrs attribute to automatically fetch the corresponding attributes/ relations and store them in the resulting rset cache and in the entities obtained by the entities() method. Note that :
| |
| priority | normal |
|---|---|
| type | enhancement |
| done in | <not specified> |
| closed by | <not specified> |
similar entities
- cubicweb #1947456 ORM should not try to re-fetch initiator relation/entity
- cubicweb #246942 supporting aggregates in SET queries
- cubicweb #1697862 ORDERBY SUM(C) seems to cancel GROUPBY
- cubicweb #509109 transitivity of relationships
- cubicweb #1381497 support substitution of list of elements passed to RQL IN predicate
[see all]
Comments
-
2010/06/18 09:52, written by sthenault
- this should have to be done on the repository side (we don't know variable's type before)
- in case of etype ambiguity, that doesn't seem feasible to me since rset rows must be consistent
- I'm strongly -1 on complete=all by default, this would imo cause performance penalty (much more data to transfer every time while most is already cached by the orm + bw compat pb)
-
2010/06/18 09:58, written by fcayre-old
-
2010/06/18 10:03, written by sthenault
-
2010/06/18 10:10, written by fcayre-old
-
2010/06/18 10:22, written by sthenault
-
2010/06/18 10:36, written by sthenault
-
2010/06/18 10:38, written by fcayre-old
-
2010/06/18 10:53, written by sthenault
- ask explicitly for completion
- in such case, rql/rset values are visibly altered
- no fetch on ambiguity
add commentIf you do not have any fetch_attrs, I do not see any performance penalty, am I right?
disabling fetch_attrs to avoid this is imo not an option.
also bw compat pb is a show-stopper
Could you develop the bw compat problem? I do not catch it. Regarding fetch_attrs, I think we misunderstood each other on that point: I do never want to disable it at any time, but to honor it even outside the ORM, in the RQL queries ; the result set would contain the columns specified in the Any clause, not more: the unlisted fetch_attrs columns would not be accessible using rset.rows[row][col] at all, but only through rset.entities(my_col).my_attribute. Ambiguity is an issue, I agree. Perhaps we could simply warn the user that the fetch_attrs was not honored for some etypes because of an etype ambiguity?
there is NO WAY to acheive this without altering data returned in the resultset. Hence the bw compat pb.
should read 'there is NO DESIRABLE WAY' :)
Of course the cursor result set will be altered, but .rows could be a property object which __getitem__ method is overloaded to achieve bw compat, and make the automatically added attributes unreachable without calling entities() on the rset.
this starts being a bit too much magic for me.
What about the rql associated to the rset, used to guess what could be get back to the entity cache? Should it be the original rql (desireable for facets for instance) ? The rewritten one (desireable to keep current entity construction mecanism) ? Should we have both ?
Grmpf. As I said, I would go for the less magic and complexity: