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

Christophe de Vienne christophe at unlish.com
Sat Aug 23 20:56:27 CEST 2014

Le 23/08/2014 19:34, aurélien campéas a écrit :
> 2014-08-23 18:43 GMT+02:00 Christophe de Vienne <christophe at unlish.com 
> <mailto:christophe at unlish.com>>:
>     [...]
>>         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.

ISession would be enough if the cube add its own little layer that logs 
all the needed data. This way it would work with alternate session backend.

That said, nothing prevents to write a cube that use its knowledge of 
the session storage to provide more informations.

The thing is : will such a cube be an actual need soon ? I think not, 
and even if, it should not make us consider the session schema as an 
official API.

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

Ok, "any cube" is not strictly true. But the exceptions should be rares 
enough to allow the session schema to remain an implementation detail.

And if at some point the session schema become used by such a cube, only 
then we can make it more official. In the mean time, let's consider it a 
hidden gear in the system, and a replaceable one.

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

Yes, but I think these cases are not a subject for now. They will imply 
things when they emerge, so we can deal with them later.

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

Agreed too, but too early IMO. It should remain an implementation detail 
for now, and until an actual need emerge.

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

I do not suggest to rule it out, just to delay the subject.

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

The thing is : session data are not "semantically" structured. The only 
semantic thing we would have (at least to start with) would be the 
Session entity.

Semantically structured session is an interesting idea, worth exploring, 
but beyond the basic need I want to address right now.

I suggest we keep this for a later discussion.

>>     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 less concepts we duplicate between cubicweb and pyramid the better.
I would say: 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.

Fine with me.

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

I probably mixed my memories about this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140823/9eb3ffbc/attachment-0186.html>

More information about the Cubicweb mailing list