mozilla-services / cliquet / 2320 / 1
100%
master: %

LAST BUILD BRANCH: 186-215-add-sqlachemy-pooling
DEFAULT BRANCH: master
Ran
Files 68
Run time 6s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 99.652%. First build
TOX_ENV=py27

push

travis-ci

leplatrem 
Pass current request along every backends methods.

**Rationale*:

This small refactor paves the way for:

* persisting backend connections on current request (instead of pull/push from queue for each operation performed with one request, e.g batched requests)
* having one transaction per request (with a tween to connect / commit). Particularly interesting for batched requests. (see https://github.com/Kinto/kinto/issues/194)
* have one event per request, with every created/updated/deleted records of a batch

Of course, it may seem ugly to pass the request, but it is advocated [in Pyramid docs](http://pyramid.readthedocs.org/en/1.5-branch/narr/threadlocals.html#why-you-shouldn-t-abuse-thread-locals):

> get_current_request function should never be called because it’s “easier” or “more elegant” to think about calling it **than to pass a request through a series of function calls when creating some API design**. Your application should instead almost certainly pass data derived from the request around rather than relying on being able to call this function to obtain the request in places that actually have no business knowing about it.

We could pass a derived info like `request.bound_data`, but I like the fact to pass the request object.

Especially because it gives a lot of freedom in possible backend implementation (*imagine a box.com storage backend where original request headers are manipulated before being sent to third party service...*)

7168 of 7193 relevant lines covered (99.65%)

1.0 hits per line

Source Files on job 2320.1 (TOX_ENV=py27)