[Cubicweb] [pyramid] Persistent session - RQL or SQL ?
aurelien.campeas at gmail.com
Fri Aug 22 22:04:30 CEST 2014
2014-08-22 20:55 GMT+02:00 Christophe de Vienne <christophe at unlish.com>:
> Hi everyone,
> We need to make decisions about the default session factory.
> Currently, pyramid_cubicweb setup a SignedCookieSessionFactory, which
> stores its datas inside a cookie. Imo it is not an acceptable default for
> cubicweb, so we need to use another one.
> The new session handler should provide session persistence out of the box
> for cubicweb applications, with no need to install extra services (ruling
> out redis for example), no extra sysadmin work, and works properly in a
> multi-instance environment (ruling out local filesystem storage).
> The answer is pretty simple : we need to store the session data in the
> The real question is, do we store the data in a ER model or directly with
> SQL ?
It doesn't matter *that much*, but ...
> The easy way is to use an ER model and RQL. Problem is: having this in the
> data model kind of makes it an official API, and exposes too much of the
> implementation details.
What implementation details ? If we define a default store strategy, it's
not only an "implementation detail".
> The risk is to have people think they can rely on those data being in the
> ER model, which may be false if an alternate session factory is used.
It's not only a risk, it' the whole point.
People going non-default will have to assume their choice of course.
Moreover, I firmly think we can have a caching mechanism (e.g. memcached)
AND a persistent db yams/rql thing for sessions at the same time.
> Using SQL directly would solve this issue, but implies a little more work.
> It would also probably be a little faster.
It would probably be only very marginally faster, for no other obvious
> Before going myself into a first implementation I would like to hear
> opinions, and we can make a decision.
> So, what do you prefer : RQL or SQL ?
I'd say: YAMS (and then, you do it with rql or sql, I woudn't care).
What's important imho is the API point so .serialize and .deserialize the
that's where the base abstraction would lie.
Then, with a reasonnable, workable default, people could be
enticed to build fancy extensions over it and do statistics, etc.
and share them.
I believe the top of the "persistent sessions" patchset would be the right
place to experiment with this.
It provides the YAMS/rql default store and only misses the proper API to
interop with Pyramid.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb