Suggestion: allow programmatically generated occurences

[ampled]

I hope you find this interesting. It could be a viable method of allowing "infinitely" recurring events.

While comparing different calendar/scheduling packages for Django, I've noticed that mostly they follow the same pattern of implementation: having a recurring event and occurences written to the database when the event is created, and allowing additional occurences to be added manually, except django-scheduler that does the complete opposite: relying completely on rrule to calculate and return an occurence should it be looked up, and storing an occurence only if it's unique in some way.

I think the advantages of either method comes down to performance and convenience. I would like my users to be able set up a schedule once and never having to think about it again, but that means I would have to set up a scheduled task to generate occurences for them every now and then if I use django-swingtime. Otherwise I could rely on rrule to do the job, but I think this could horribly affect performance if a large amount of users have to wait for rrule to calculate an occurence's existense when it's looked up. ( I don't know much about this, so forgive me if I'm wrong )

So what about a combination of both? I suggest keeping the current method of storing occurences to the database, but if an occurrence-lookup fails it uses rrule-arguments stored in the Event model to decide if the event should have an occurence there.

[dakrauth]

I've been thinking about doing something along the lines you suggest for a very long time and am constantly vacillating between various implementations. Obviously, there is nothing stopping someone from creating a derived model to suit their needs, so I've opted to just keep the app as simple as possible. However, several folks have expressed a similar interest, as well as requesting either docs or explicit mechanisms for extending the existing functionality. I'm prepared to create begin work on a branch to explore some options and am hoping you would be interested in reviewing and providing feedback.

[nimbiotics]

I have no experience collaborating on projects and would consider my experience with Python/Django as Intermediate, but far from Advanced, let alone Pro. Yet I would very much like to participate in the fork if you don't mind as, not only would I like the experience, but also am in the need for such tool for a future project.

Dtb/Gby

Mario R. Osorio A.S. of Computer Programming and Analysis Web page: http;//mario.osorio.solutions http://http%3B//mario.osorio.solutions Email: mario@osorio.solutions mario@osorio.solutions Just Choose Python! http://www.gentoogeek.org/files/choose_python.pdf

“If I had asked people what they wanted, they would have said faster horses.” ― Henry Ford

http://goo.gl/t2Hzgo

On Fri, Feb 12, 2016 at 9:39 AM, David A Krauth notifications@github.com wrote:

I've been thinking about doing something along the lines you suggest for a very long time and am constantly vacillating between various implementations. Obviously, there is nothing stopping someone from creating a derived model to suit their needs, so I've opted to just keep the app as simple as possible. However, several folks have expressed a similar interest, as well as requesting either docs or explicit mechanisms for extending the existing functionality. I'm prepared to create begin work on a branch to explore some options and am hoping you would be interested in reviewing and providing feedback.

— Reply to this email directly or view it on GitHub https://github.com/dakrauth/django-swingtime/issues/18#issuecomment-183355313 .

[rcooke]

In theory, rrules can go forever. And you can programmatically generate events from the rrules forever.

In reality, clients tend to have a fixed time span of interest - usually 12-13 months. So it makes perfect sense to "discard" the perfect rrule behavior and spew out the repeats as discrete events, like Swingtime does. Keeping them tied to an event type allows the client to further tweak event dates belonging together. And working with discrete events makes all other logic (like room loading) much easier. Since your analyzing physical records in the db, not having to constantly re-generate event lists from multiple rrules.

I think that made sense back in the days of expensive hard disk space. Not so much now....