cubicweb #2363313 _cw gets hosed after a .commit() [deprecated]
There exists a free_cnxset param which is valued to True by default and will "free" the cnx. It should be False by default. | |
| priority | important |
|---|---|
| type | bug |
| done in | 3.17.0 |
| load | 0.000 |
| load left | 0.000 |
| closed by | <not specified> |
similar entities
- What's new in CubicWeb 3.16
- 1 to 1 relationships and subresources in REST APIs | Technology on Heels with Lyst Engineering (http://developers.lyst.com/2015/02/20/1-to-1-relationships-and-subresources-in-rest-apis/)
- cubicweb #1568456 login parameter should be mandatory for cubicweb.dpapi.connect
- cubicweb-blog #1337569 Implement the Metaweblog API
- cubicweb #5414757 [dataimport] more api specification
[see all]
Comments
-
2012/05/16 16:00, written by sthenault
-
2012/05/16 16:13, written by acampeas
- the doc is almost silent on the topic (except the explanation-less "you should not .commit() explicitly" and vague instructions in the chapter about unit tests)
- on the doc topic, the online search yields even less results (this has been broken for months)
- silent failure if this happens through pyro
- this is just not the right API
-
2013/03/28 17:02, written by acampeas
-
2013/03/28 17:12, written by sthenault
add commentcnx handling is cw's internal. Default value of free_cnxset param is intended and should not be changed without changing the whole cnxset handling.
This kind of point usually comes from mis-usage of repository session in test.
It comes from client-(as in "customer")-written code. Though from my own experience I finally identified that piece of code as the culprit after a several-hours ride, I note that:
I'm perfectly fine with "changing the whole cnwset handling" if this is what it takes. At last this might be mentioned in your blog post about cw 4 (or "cleanued-up").
This may be addressed post cw 3.17 as this version clarifies a lot the session/transaction handling.
this is rather related to database connections handling, which won't change in 3.17.
IMO, we're still talking about a documentation issue, which sound minor at the time this code was written as it's about an internal api (public api is dbapi.commit/rollback, not repository.session.commit/rollback).
But request/session similarity and their usage in tests expose this more than desired and causes such problem.
Side note: title and description could be a bit more specific and some example case would be welcome.