Dear all,

My application uses a calendar which I'm populating using an array of
indexed RollingEvent objects. A RollingEvent is one of a series,
multiplied from its original Event's repeat options (daily, weekly,
fortnightly etc). The idea is that when a user saves an Event, the app
uses a loop to generate and store all the RollingEvents for the coming
year.

So a new Event is added, add_rolling_event is called within the loop
(I've omitted most of the params for readability):

 def add_rolling_event(id, title, calendar_date)
    @events[calendar_date.to_date] ||= []
    @events[calendar_date.to_date] << RollingEvent.new(id, title,
calendar_date)
 end

The indexing works well, as in the calendar view I can quickly pull out
the RollingEvent objects for that specific day. For the moment, whenever
an Event is edited the entire @events array is reset and a routine loops
through all Events to re-generate RollingEvents.

I'm trying to speed up the process by just deleting the RollingEvents
pertinent to the Event that's being edited, then calling
add_rolling_event for the Event in question.

I have 3 questions:

1. Is using an indexed array actually faster than picking out events on
the day using @events.select { |e| e.calendar_date == date }? It would
be good to uncomplicate this if possible.

2. It seems that if I were to use delete_if on an indexed array, I'd
have to loop through the array of RollingEvent objects for each indexed
day. Am I right in assuming that this is uber-inefficient? Is there a
better way to do this?

3. Currently @events (in a model called Event_Roster) and RollingEvents
are all non-database-backed for performance, and stored in a memcached
session. My concern has always been that - hypothetically - one could
have 10 daily Events, resulting in 3650 RollingEvents. This doesn't seem
to be a scalable solution, and the read/writes to and from the database
would be costly. Would you advise writing all RollingEvents to a
database, and is the performance hit negligable?

Thanks!
-- 
Posted via http://www.ruby-forum.com/.