You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Brice Hamon <no...@gmail.com> on 2013/07/16 16:51:29 UTC

forms and Session

Hi guys,

I have 2 questions:

1) when using SESSION, is there a way to get notified when a session
expires or is closed by rivet? I need to do some cleanup on my side
when a user goes away.

2) Is there something special to do before using forms? I am getting a:

invalid command name "::rivet::form"
    while executing
"::rivet::form myform -defaults response -method post -action {logout}
-name logout"

while all other packages so far are working fine (DIO, SESSION).

Thank you,

B.

Re: forms and Session

Posted by Brice Hamon <no...@gmail.com>.
Hi Massimo.

Understood.

I will let this part for later, and keep thinking of how to do this
efficiently and elegantly to keep options open.

Thank you for your help.

B.

On Tue, Jul 16, 2013 at 12:11 PM, Massimo Manghi <ma...@unipr.it>wrote:

> On 07/16/2013 05:19 PM, Brice Hamon wrote:
> > Hi Massimo,
> >
> > Thank you for your quick reply.
> >
> > OK the form is working.
> >
> > For the session, if I understand correctly, the Session class just does
> > a sql delete based on last update time.
>
> yes, the last update is the key piece of information for deciding
> whether run the GC.
>
> > But only the DB knows what sessions will be deleted.
>
> rows in the table rivet_session_cache are deleted accordingly when a
> session is deleted from rivet_session. This is a useful case to get
> introduced to DBMS triggers. Consider to exploit the interface to the
> rivet_session_cache table (with method 'fetch' and 'store') for storing
> session specific data, it's simple, useful and general enough for
> storing keyed data
>
> >
> > What about doing a more elaborate GC with a default Session method
> > called with the "to be deleted" session?
> >
> > Makes sense?
> >
>
> you mean a callback to be run for every row? It would make the process
> way slower than with triggers I suppose....furthermore triggers and
> stored procedure force you to think first in terms of DB design and then
> of everything you can do with Tcl
>
> When I thought of subclassing or filters I was thinking of procedures to
> be done that couldn't be put in a stored procedure because external to
> the DBMS.
>
>
> > Thank you,
> > B.
> >
> >
>
> --
> -- Massimo Manghi
>
> Dipartimento di Neuroscienze
> Unità di Biofisica e Fisica Sanitaria
> via Volturno 39
> 43125 Parma
>

Re: forms and Session

Posted by Massimo Manghi <ma...@unipr.it>.
On 07/16/2013 05:19 PM, Brice Hamon wrote:
> Hi Massimo,
> 
> Thank you for your quick reply.
> 
> OK the form is working.
> 
> For the session, if I understand correctly, the Session class just does
> a sql delete based on last update time.

yes, the last update is the key piece of information for deciding
whether run the GC.

> But only the DB knows what sessions will be deleted.

rows in the table rivet_session_cache are deleted accordingly when a
session is deleted from rivet_session. This is a useful case to get
introduced to DBMS triggers. Consider to exploit the interface to the
rivet_session_cache table (with method 'fetch' and 'store') for storing
session specific data, it's simple, useful and general enough for
storing keyed data

> 
> What about doing a more elaborate GC with a default Session method
> called with the "to be deleted" session?
> 
> Makes sense?
> 

you mean a callback to be run for every row? It would make the process
way slower than with triggers I suppose....furthermore triggers and
stored procedure force you to think first in terms of DB design and then
of everything you can do with Tcl

When I thought of subclassing or filters I was thinking of procedures to
be done that couldn't be put in a stored procedure because external to
the DBMS.


> Thank you,
> B.
> 
> 

-- 
-- Massimo Manghi

Dipartimento di Neuroscienze
Unità di Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org


Re: forms and Session

Posted by Brice Hamon <no...@gmail.com>.
Hi Massimo,

Thank you for your quick reply.

OK the form is working.

For the session, if I understand correctly, the Session class just does a
sql delete based on last update time.
But only the DB knows what sessions will be deleted.

What about doing a more elaborate GC with a default Session method called
with the "to be deleted" session?

Makes sense?

Thank you,
B.




On Tue, Jul 16, 2013 at 11:04 AM, Massimo Manghi <ma...@unipr.it>wrote:

> Hi Brice
>
> On 07/16/2013 04:51 PM, Brice Hamon wrote:
> > Hi guys,
> >
> > I have 2 questions:
> >
> > 1) when using SESSION, is there a way to get notified when a session
> > expires or is closed by rivet? I need to do some cleanup on my side
> > when a user goes away.
> >
>
> Currently I can think of only 2 possible ways:
>
>  1 - DBMS triggers: if your cleanup is related to other data stored in
> other tables you may design your DB schema so that you can use the
> session_id column as key for picking the rows you want to remove (see
> Mysql manual for triggers and stored procedures)
>
> 2 - Subclass Rivet's Session class and override the
> do_garbage_collection method. Just remember to call the superclass
> method after you have carried out your cleanup tasks.
>
> I proposed to reimplement Session as an TclOO class preserving the
> interfaces as much as possible: using OO system would make available to
> the programmer filter methods that could be configured at run time
>
> > 2) Is there something special to do before using forms? I am getting
> > a:
> >
> >
> > invalid command name "::rivet::form" while executing "::rivet::form
> > myform -defaults response -method post -action {logout} -name
> > logout"
>
> package require form should create the form command in the global
> namespace, not within the ::rivet namespace (we ought to introduce a
> namespace for it)
>
> >
> > while all other packages so far are working fine (DIO, SESSION).
> >
> > Thank you,
> >
> > B.
> >
>
>
> --
> -- Massimo Manghi
>
> Dipartimento di Neuroscienze
> Unità di Biofisica e Fisica Sanitaria
> via Volturno 39
> 43125 Parma
>

Re: forms and Session

Posted by Massimo Manghi <ma...@unipr.it>.
Hi Brice

On 07/16/2013 04:51 PM, Brice Hamon wrote:
> Hi guys,
> 
> I have 2 questions:
> 
> 1) when using SESSION, is there a way to get notified when a session
> expires or is closed by rivet? I need to do some cleanup on my side
> when a user goes away.
> 

Currently I can think of only 2 possible ways:

 1 - DBMS triggers: if your cleanup is related to other data stored in
other tables you may design your DB schema so that you can use the
session_id column as key for picking the rows you want to remove (see
Mysql manual for triggers and stored procedures)

2 - Subclass Rivet's Session class and override the
do_garbage_collection method. Just remember to call the superclass
method after you have carried out your cleanup tasks.

I proposed to reimplement Session as an TclOO class preserving the
interfaces as much as possible: using OO system would make available to
the programmer filter methods that could be configured at run time

> 2) Is there something special to do before using forms? I am getting
> a:
> 
> 
> invalid command name "::rivet::form" while executing "::rivet::form
> myform -defaults response -method post -action {logout} -name
> logout"

package require form should create the form command in the global
namespace, not within the ::rivet namespace (we ought to introduce a
namespace for it)

> 
> while all other packages so far are working fine (DIO, SESSION).
> 
> Thank you,
> 
> B.
> 


-- 
-- Massimo Manghi

Dipartimento di Neuroscienze
Unità di Biofisica e Fisica Sanitaria
via Volturno 39
43125 Parma

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org