[Cubicweb] [pyramid] Persistent session - RQL or SQL ?

aurélien campéas aurelien.campeas at gmail.com
Fri Aug 22 22:04:30 CEST 2014


Hi,

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
> 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 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
benefit.


>
> 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
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.

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.

Regards,
Aurélien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140822/3e8b50a0/attachment-0050.html>


More information about the Cubicweb mailing list