Skip to content
This repository has been archived by the owner. It is now read-only.

Recurring events do not appear to extend beyond November 2008 #170

Closed
macosforgebot opened this issue Dec 10, 2007 · 15 comments
Closed

Recurring events do not appear to extend beyond November 2008 #170

macosforgebot opened this issue Dec 10, 2007 · 15 comments

Comments

@macosforgebot
Copy link

@macosforgebot macosforgebot commented Dec 10, 2007

dekkerdreyer@… originally submitted this as ticket:207


Lightning, connected to Darwin Calendar Server, doesn't show repeating events past November 2008. The same event, saved on a WebDav, works fine.

I suspected this was a problem with Lightning/Sunbird, but it now appears to be a Calendar Server bug. There are some details related to what queries show repeating events and what queries do not. Please check this bug entry in bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=407588

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jan 23, 2008

@wsanchez originally submitted this as comment:1:⁠ticket:207

  • Owner changed from @wsanchez to @cyrusdaboo
  • Priority changed from 5: Not set to 2: Expected
  • Milestone set to 1.2
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Mar 10, 2008

@wsanchez originally submitted this as comment:2:⁠ticket:207

  • Priority changed from 2: Expected to 1: Blocker
  • Milestone changed from 1.2 to 1.3
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 24, 2008

@agx originally submitted this as comment:3:⁠ticket:207


Peter Mogensen noticed that DCS (1.2) will not return an event instance more than 356 days from the creation of the event in a calendar-query.

He found that these events are not put into the TIMESPAN index, which means that they are not returned by a search using the index.

Searches seems to not use the index when there's a time-range element in the filter, but the exception detecting this is only thrown from the filter expression generator for prop-filters, ... which again means that if you don't have a prop-filter in your query, you'll get a search using the index, which will ignore these 356+ days events.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 24, 2008

@wsanchez originally submitted this as comment:4:⁠ticket:207


The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit.

If we have expanded to the limit, then any queries that goes beyond the limit would have to read the icalendar data to see if that event matches (far more expensive, but the idea is that such queries should be rare).

The code is apparently not working as I described.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 31, 2008

apm@… originally submitted this as comment:5:⁠ticket:207


Replying to wsanchez@apple.com:

The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit.

Yes but that indication is stored in the RESOURCE table in RECURRANCE_MAX and unless I'm sorely mistaken a simple grep will show that RECURRANCE_MAX is used no where in the 1.2 code except in "create table" statements and in the "insert into" statement which first inserts the event into the RESOURCE table. (index.py). No where is the value brought out farther.

I'm sad to see this bumped to milestone 2.x. I would suspect this to be a serious blocker for any practical use. No events of the "same time, next year" kind can be used in the calendar. Anniversaries and every other event more than 356 days into the future will also disappear.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Jul 31, 2008

@wsanchez originally submitted this as comment:6:⁠ticket:207


Right, the bug is that we handling RECURRANCE_MAX correctly.

Sorry the milestone isn't satisfactory for you, but the reason its not at an earlier milestone is that desktop clients like iCal tend to do this sort of query based on their own local cache of everything in your calendar and not via CalDAV. Web clients which don't cache data are going to have to hit the server, but at the moment the number of CalDAV clients I'm aware of is rather low, and are all desktop clients.

iCal also happens to be a bit of a priority for us at Apple, and we don't have a lot of incoming patches from outside of the Apple team in this area yet. If you want to pitch in or someone else manages to send us some fixed, I'd be happy to pull the milestone in.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Aug 13, 2008

apm@… originally submitted this as comment:7:⁠ticket:207


Suggestion for solution posted to -dev list. Please comment.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Aug 14, 2008

@wsanchez originally submitted this as comment:8:⁠ticket:207

  • Status changed from new to closed
  • Resolution set to fixed

r2825

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Aug 14, 2008

@wsanchez originally submitted this as comment:9:⁠ticket:207

  • Status changed from closed to reopened
  • Resolution fixed deleted

Whoops, wrong ticket

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Aug 22, 2008

apm@… originally submitted this as attachment:Ticket207.patch:⁠ticket:207


Proposal for patch against CalendarServer 1.2 sources

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Sep 2, 2008

apm@… originally submitted this as attachment:Ticket207-2.patch:⁠ticket:207


fixed iCalendar export bug

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Sep 15, 2008

@wsanchez originally submitted this as comment:10:⁠ticket:207


At a glance, this looks OK, though we will need some unit tests.

Coding guidelines are here: source:CalendarServer/trunk/HACKING.

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Oct 28, 2008

@wsanchez originally submitted this as comment:11:⁠ticket:207

  • Milestone changed from CalendarServer-2.x to CalendarServer-2.0
@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Dec 10, 2008

@wsanchez originally submitted this as comment:12:⁠ticket:207

  • Status changed from reopened to closed
  • Resolution set to Software changed

Morgen fixed this in r3489

@macosforgebot
Copy link
Author

@macosforgebot macosforgebot commented Dec 10, 2008

@wsanchez originally submitted this as comment:13:⁠ticket:207


(Thanks for the patch!)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.