[META} reduce date repeat memory footprint

I'd like to know that too. I have the same problem.

@date repeat api developer
Y YOU STORE DIS IN DB??

hey asiby, unfortunately all date repeats are stored in the db...

I had a discussion about this with the author of the date repeat api here: http://groups.drupal.org/node/221229#comment-782368

She dodged the issue in the end, so don't get your hopes up that she will make the date repeat api usable :(

Clearly there is a need for change here.

Date repeats works in many cases has various issues.

One is as you've outlined memory efficiency, another is that views support is ok but in my opinion limiting.

A third is what happens if you have a repeating event but one of those events is slightly different, it could be time or other content or fields related to it. For example the last repeated event before 25th December is the Christmas Party.

I have been looking for a solution that broke out repeated dates so each date was it's own node. There are various D6 and a couple of D7 contributed modules for this but none is satisfactory. see https://drupal.org/node/894680. This approach is good for all sorts of reasons as it meets the use case where a repeated date instance needs to be different, it

In a presentation at a conference Karen the main committer of the date module intimated that date repeat needs looking at, but that it will not be in D8 Core, this is actually an opportunity presenting itself.

If the Date Team proceed with "Date in Eight" as it is known, but if the api is monitored for changes (and the "nodeapi" side of core as well) then the opportunity exists to create a better date repeat that MAY be more memory efficient, meet the needs of anyone who wants better Views integration of repeating dates and meet all sorts of other requirements.

So as I see it the solution would:

1. Have a UX that allows the creation of date repeating nodes or entities as now but provide the option (and explain why and when to use it) to break out each repeated date into a separate node or entity.
2. Store the Date repeat sequence in a manner that exposes the originating node or entity plus all child nodes or entities that are created and the rules that create them, this could be an entity that stores the ical rrule used now, a YAML file for CMI in D8 and any comments needed (this is just of the top of my head btw)
3. Have a UX that allows removal of repeated dates as a whole or in part (clearly a mechanism to handle entities or nodes changed after the event may be necessary) as this will be needed.
4. Could not logically be open ended and indeed I can see no logic for ever making a date repeat on friday forever (who knows what technology will look like in five years time let alone 20 years), the example raised by asiby is a good example of the sort or reasonable limits.
5. Would not eat memory, since a view of a number of dates does not do so if each is an individual node I cannot see why a mechanism that breaks out repeated date events into individual nodes should do so either.
6. Have a mechanism that preserves times and date and end times if set in the parent entity or node.
7. Ideally have functionality that is reusable. I can envisage that other entity or content types may be creatable from a repeated date, so for example work shifts for events. Thus any solution needs an API to make this work.

These are my thoughts but based on studying, testing and working with date based nodes and entities for a couple of years and is entirely up for discussion. It would be nice to have some input from the Date module and date repeat module devs as to how plausible this is.

Fixed a typo

Old issue but still contain valid points so I think we should keep it open, but perhaps change the scope to a meta task trying to address memory consumption regarding date repeat with many entries?