[Cubicweb] [pyramid] Persistent session - RQL or SQL ?
Christophe de Vienne
christophe at unlish.com
Sat Aug 23 18:43:19 CEST 2014
Le 22/08/2014 22:04, aurélien campéas a écrit :
> 2014-08-22 20:55 GMT+02:00 Christophe de Vienne <christophe at unlish.com
> <mailto: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 database.
> 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 whole point of my message was the "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".
I think it is.
My point is that the only mean to access the session data is the session
API. In the pyramid world, this API is called ISession, and outside of
this interface the /whole/ application code should be totally
The default store strategy should only match the requirements I
mentioned because it would provide a sane-enough behavior without
changing anything in the way we deploy cubicweb today.
And I should be able, not as an application developer but as a sysadmin,
to choose a different backend without touching any line of code in any cube.
> 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.
Yes, but assuming this choice should never mean loosing any features. It
should only mean maintaining an extra service (redis for example) and
configure things properly.
And it is cheap to obtain this if we stick to the ISession API.
> 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.
Persistence can be provided by redis. And in that case we don't want
persistence to be also in the database.
> 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).
I do not mind using YAMS and even RQL. BUT it would be with a clear
statement that these structures are NOT part of the API and should NEVER
be accessed by user code.
> What's important imho is the API point so .serialize and .deserialize
> the session object.
> 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.
The ISession/ISessionFactory can be implemented in alternate ways, with
a thin wrapper over the actual storage (which is still implementing the
It would be enough to implement any fancy extensions you can imagine
around sessions. Bottom line is : we don't need to access the storage
itself for that.
> 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.
The persistence should not be part the cubicweb sessions implementation,
at least not if we are talking about pyramid integration.
The YAMS & RQL you wrote in the patch can be reused in a ISession
implementation in pyramid_cubicweb though.
That said the patch pile your refer to contains something important for
the future of pyramid integration, which is short-lived session objects.
Using them will make the current pyramid_cubicweb implementation more
efficient (see the XXX comments in core.py).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb