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: [email protected] [email protected]
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 [email protected]
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
#18 (comment)
.

[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....