Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
#207: Recurring events do not appear to extend beyond November 2008 -------------------------------------+-------------------------------------- Reporter: dekkerdreyer@… | Owner: sagen@… Type: Defect | Status: closed Priority: 1: Blocker | Milestone: CalendarServer-2.0 Component: Calendar Server | Severity: Serious Resolution: Software changed | Keywords: -------------------------------------+-------------------------------------- Comment(by wsanchez@…): (Thanks for the patch!) -- Ticket URL: <http://trac.calendarserver.org/ticket/207#comment:13> CalendarServer </> HTTP/WebDAV/CalDAV Server
CalendarServer wrote:
#207: Recurring events do not appear to extend beyond November 2008 -------------------------------------+-------------------------------------- Reporter: dekkerdreyer@… | Owner: sagen@… Type: Defect | Status: closed Priority: 1: Blocker | Milestone: CalendarServer-2.0 Component: Calendar Server | Severity: Serious Resolution: Software changed | Keywords: -------------------------------------+--------------------------------------
Well... this bug has a corollary. With the ability to create events longer into the future the possibility that a user will create an event with more than "max_allowed_instances" (currently 1000) increases. From instance.py: # The maximum number of instances we will ezpand out to. # Raise a TooManyInstancesError exception if we exceed this. max_allowed_instances = 1000 ... which will make events disappear again. I see no good solution to this without some mechanism for the user to clean up old calendars, so the don't unnecessarily contain - say - 5 year old daily events. /Peter
That's probably worth filing another ticket. We should have some sort of handling for that case. -wsv On Jan 28, 2009, at 2:04 AM, Peter Mogensen wrote:
CalendarServer wrote:
#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------- +-------------------------------------- Reporter: dekkerdreyer@… | Owner: sagen@… Type: Defect | Status: closed Priority: 1: Blocker | Milestone: CalendarServer-2.0 Component: Calendar Server | Severity: Serious Resolution: Software changed | Keywords: ------------------------------------- +--------------------------------------
Well... this bug has a corollary. With the ability to create events longer into the future the possibility that a user will create an event with more than "max_allowed_instances" (currently 1000) increases.
From instance.py:
# The maximum number of instances we will ezpand out to. # Raise a TooManyInstancesError exception if we exceed this. max_allowed_instances = 1000
... which will make events disappear again.
I see no good solution to this without some mechanism for the user to clean up old calendars, so the don't unnecessarily contain - say - 5 year old daily events.
/Peter
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
Wilfredo Sánchez Vega wrote:
That's probably worth filing another ticket. We should have some sort of handling for that case.
Will do - as soon as Trac stops throwing exceptions at me. :) /Peter PS: From http://trac.calendarserver.org/ Traceback (most recent call last): File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 367, in send_error 'text/html') File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", line 706, in render_template if not req.session or not int(req.session.get('accesskeys', 0)): File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 194, in __getattr__ value = self.callbacks[name](self) File "/opt/local/lib/python2.5/site-packages/trac/web/main.py", line 264, in _get_session return Session(self.env, req) File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", line 156, in __init__ self.promote_session(sid) File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", line 214, in promote_session "WHERE sid=%s OR sid=%s ", (sid, self.req.authname)) File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) ProgrammingError: current transaction is aborted, commands ignored until end of transaction block
participants (3)
-
CalendarServer
-
Peter Mogensen
-
Wilfredo Sánchez Vega