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
- TheCubicWebBook #1231143 [rql] add documentation for group_concat usage
- cubicweb #1356884 ms: tb on rql generated by the no_relation feature of RelationFacet
- cubicweb #615294 reuse rql built through the use of facets
- cubicweb #1922945 conditional log of rql queries
[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: