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-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
