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 <massimo.man...@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 >
