Rails - Sep 2005 - Expiring related 'incomplete' objects along with the session

All,

I''m a Rails novice, currently planning a messaging application,
and have a situation where I would like to keep track of some
''partially complete'' objects in a session.

These objects will need to be in the database, so I will just be
storing their ids in the session, but I wish them to be destroyed
when the session is expired. I''m trying to work out a generic
mechanism to do this.

My initial thoughts are:

  - use ActiveRecordStore, with the updated_at field as suggested
    in AWDwR.

  - then either:

   (A) Store the session ID in a field called ''incomplete'' on
each of
   the tables I am concerned with, and purge them at the same time as
   I purge the related session

  - or

   (B) use a naming scheme on session keys to identify objects I wish
   to be destroyed, so on identifying sessions to expire, I can
   inflate the sessions, find and destroy the so-named objects.

It seems to me that (A) means modifying a generic session sweeper to
sweep each of the tables I want to expire, meaning the sweeper
script has to be updated as the application development progresses,
and (B) is more resource intensive.

Also, I''m not actually sure right now what I have to do to inflate the
sessions in strategy (B). I was figuring on a runner script, but I''m
not sure where to go from there.

Finally, both of these strategies tie me to ActiveRecordStore, which
is probably OK for now, but might be a problem when my app becomes
outrageously successful.

Am I missing something ideological here? Is there something simpler,
or am I heading for danger?

Thanks in advance (and my apologies if I''ve missed anything blindingly
obvious and ruined your coffee break with repetitive nonsense).
	
	Mike Houghton

On Sep 8, 2005, at 5:58 PM, Michael Houghton wrote:
> These objects will need to be in the database, so I will just be
> storing their ids in the session, but I wish them to be destroyed
> when the session is expired. I''m trying to work out a generic
> mechanism to do this.
Is there a reason you''re not using the transaction support in your db?

On the surface, it seems like a good match.

Deirdre Saoirse Moen wrote:
> On Sep 8, 2005, at 5:58 PM, Michael Houghton wrote:
> 
>> These objects will need to be in the database, so I will just be
>> storing their ids in the session, but I wish them to be destroyed
>> when the session is expired. I''m trying to work out a generic
>> mechanism to do this.
> 
> 
> Is there a reason you''re not using the transaction support in your
db?
> 
> On the surface, it seems like a good match.
It does?  Sounds to me like he''s trying to keep partial objects across
requests - I thought it never made sense to keep transactions open that
long?  For a start, you''d have to keep the database connection in the
session, which is a right pain.

You could flip the problem on its head, and do:

create table partials (
	id ...,
	session_id ...,
	type varchar(255),
	primary_key int );

Store the session id, classname and object id in the partials table, and
you can reload your partials easily, and also reap the session
efficiently.  There''s no need for Partial to be an ActiveRecord, but it
might make things a bit easier.

That way you can easily pick out the partials from either the main AR
table for the class, or from a separate class-partial table that acts as
a temporary holder until the object needs to be persisted.  Actually,
thinking about it, that last way might be generally better, because
it''d
let you run round collecting data that might get persisted to more than
one class, but you don''t know what the full layout''s going to
be until
you''re done...  Hmm.  Might go away and have a think about that.

If I''ve just described ARS, I apologise - I''ve yet to read
AWDwR, and I
don''t feel ready to delve into the code before my first coffee.  Is
there a nice explanation of what it does somewhere convenient?

-- 
Alex

> From: Deirdre Saoirse Moen
<deirdre-mzk6fgDMp2XR7s880joybQ@public.gmane.org>
>
> On Sep 8, 2005, at 5:58 PM, Michael Houghton wrote:
>
>> These objects will need to be in the database, so I will just be
>> storing their ids in the session, but I wish them to be destroyed
>> when the session is expired. I''m trying to work out a generic
>> mechanism to do this.
>
> Is there a reason you''re not using the transaction support in your
db?
>
> On the surface, it seems like a good match.
Sorry, I think I might not have explained myself too well there
(the perils of working late).

The short version is:

- I have objects created in the database that are linked to a user''s
editing session.

- If the user does not complete the editing session (say they back
out, close their browser, it crashes, whatever), I will have objects
in the database that are now connected to an expired session.

- When I come to expire this dead session from the database, I need to
remove these related objects. I am trying to develop a generic
mechanism to expire these objects - hence my question.

I''m not sure how transaction support can help me solve this long-
lived problem. Am I missing something?

	Mike Houghton