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

aurélien campéas aurelien.campeas at gmail.com
Sat Aug 23 19:34:19 CEST 2014


2014-08-23 18:43 GMT+02:00 Christophe de Vienne <christophe at unlish.com>:

>
> Le 22/08/2014 22:04, aurélien campéas a écrit :
>
> 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 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 implementation
> agnostic.
>

Satisfying ISession is one (probably small) thing. It will be quickly
tackled.

I disagree with the "outside .... agnostic" part.

Let say I write a "session analytics" cube, I will want it to use the
session schema, not ISession,
which is a simple interface for the pyramid interop.


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

I disagree with the "any cube" premise. But indeed, most cubes shouldn't
have to care.


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

As I suggest, it may imply losing features in very specific cases.


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

Let's not confuse persistence with semantics. This is probably a weakness
of my presentation of the "persistent sessions" patch set.

I'm not using yams/rql merely because I'm a lazy implementer, I would like
some specialized cubes to operate on the data.

Also let's remember that the initial point of "persistent sessions" is not
much
persistence itself but the ability to have an out-of-process store for all
the sessions
of a cubicweb instance (regardless of how many process-based "workers"
serve it).

A pure in-memory solution like memcached does it well (and I have another
patch set
to prove it :)).

But then, persistence WITH yams/rql brings something new and potentially
interesting.


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

This is obviously not yet settled and I don't want to force anything but I
suspect standardizing on a yams/rql has a merit of its own which
should not be downplayed.


>
>
>   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 same
> interface).
>
> 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.
>


Another pow: "semantic" data is not just about persistence or storage.
It's about how we manipulate the data.

I'm not thrilled by yet another OO api beyond the Pyramid ISession
requirements.


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

Maybe. Maybe not.


>
> The YAMS & RQL you wrote in the patch can be reused in a ISession
> implementation in pyramid_cubicweb though.
>

I'd like it, yes.


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

Humm, I don't remember the cw 3.21 patch set containing anything for
short-lived sessions.

However I've recently written something targeted at 3.20 (our next feature
release) which
addresses this (the main use case today is not piling useless sessions when
using
the signedrequest cube).

Regards,
Aurélien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140823/cbd32b20/attachment-0186.html>


More information about the Cubicweb mailing list