there's no such thing as a db that holds records just for the duration of a session automatically (with a session being n>1 requests).
Just add the usual suspects to the table...."updated_on", a "user_id" and a "status" column, with a default "temp" and change it to "confirmed" as soon as the user submits the data. Then put something in cron (or in the scheduler) to erase all records that are not "confirmed" once a day. Or, track the ids being edited by the user in session and upon submission erase/modify/store based on the ids stored in session. PS: sqlite:memory holds on just for a single request. On Tuesday, January 22, 2013 12:38:42 AM UTC+1, Tim Richardson wrote: > > I want a controller that fetches a user-chosen subset of data via JSON > from an external site, and then presents that for review using smartgrids. > Being lazy, I could put the fetched data into a couple of tables. There is > a one-to-many relationship in the data (orders and order lines). > But the fetched subset is session specific: another user may be looking at > a different subset. > This application is backended with SQL Server but sqlite would be fine for > this temporary data. There is no need to refer to any existing tables so a > separate database is fine. > > I could use tables and put a session id in a column, to keep different > users 'sandboxed' to their own requests. But this means I have to clean up > old sessions. > sqlite has temporary tables which survive for the current database > connection, which I suppose means they would survive for the current web2py > action, not for the current session, although I think this could still work > for my requirement. > > I think this problem has been solved before, although I couldn't find what > I was looking for by searching. There was a discussion in 2009 about using > sqlite:memory but it didn't seem very conclusive. > --
