Add last_occurrence

[dlee]

We want to store schedules in the database, and require a way to quickly query whether a schedule (and all its occurrences) overlaps a certain time span. In order to do this, we want to store the beginning/end boundaries of the schedule.

Getting the beginning boundary is easy, since it's just the schedule.start_time, but there is no way to get the last occurrence (our non-performant workaround is to do schedule.all_occurrences.last). It would be great to have a schedule.last_occurrence.

[forrest]

The internal code iterates through all occurrence until it hits the end point. As a result, a method could be added which performs your approach, but there is no way to just arrive at the last date.

Seeing as all calculations are performed in memory, what kind of delays are you seeing from the execution of schedule.all_occurrences.last? There are a number of locations where performance for schedules containing a large number of rules could be improved, if performance becomes a real issue.

[dlee]

The internal code iterates through all occurrence until it hits the end point. As a result, a method could be added which performs your approach, but there is no way to just arrive at the last date.

Are you sure "there is no way" to calculate the last date without iterating through all occurrences? I would assume there's a programmatic way to determine the last occurrence without doing the brute-force approach.
Seeing as all calculations are performed in memory, what kind of delays are you seeing from the execution of schedule.all_occurrences.last? There are a number of locations where performance for schedules containing a large number of rules could be improved, if performance becomes a real issue.

The delays are simply that it returns slowly. It's not slow enough to notice if you calculate one last occurrence, but it's noticeable when you have to calculate the last occurrence for many schedules.

[forrest]

I'm pretty sure. Because there are so many possible rules, and the ability to have multiple rule on a single schedule, it can become extremely complicated. DST, variable month lengths, leap years, etc make it additionally complex. Often, you must know when the previous item is to calculate the next occurrence.

I'm not the library maintainer/author however, so @seejohnrun can give you a better answer.

[ericcf]

As a workaround, you could add a column in the database for the last_occurrence_at and cache the value up front when the rules change.

[dlee]

Yup, that's what I'm already doing. I just wanted to make the initial calculation fast as well.

On Nov 19, 2012, at 9:44 AM, Eric Carty-Fickes [email protected] wrote:

As a workaround, you could add a column in the database for the last_occurrence_at and cache the value up front when the rules change.

—
Reply to this email directly or view it on GitHub.

[avit]

Keep in mind that a rule must be terminating? == true for it to have a last occurrence, it would just return nil otherwise.

It should work if we make it possible to jump backwards from a rule's until time, but currently everything is designed around jumping forward and it'll require some work to change that.

For rules limited by count, it won't be so easy to optimize.

[seejohnrun]

count is my nightmare :)