Modifying event duplicates persisted occurrences

[bartekgorny]

If you change start/end of an event which has some persisted occurrences, the original occurrences reappear thus causing duplication (reported by gautamadude).

[bartekgorny]

There is a test which currently fails.

There is a reference page with some insight here: https://github.com/bartekgorny/django-schedule/wiki/Modifying-events - solving the issue requires some design decisions relating to logic rathere then implementation.

[keiouu]

I fixed this by doing the following:

models/events.py:
class Event(models.Model):
def _get_occurrence_list(self, start, end):

line 135:
occurrences.append(self._create_occurrence(o_start, o_end))
changed to:
occurrences.append(self.get_occurrence(o_start))

But I'm not sure if this breaks anything elsewhere... everything worked in my project..

This worked for me because:

• I believe if one occurrence is edited, it is an exception to a rule for example: a sick day caused the work schedule to change
• I believe that exception should become a separate entity, as it is an exception..
  • Could have a setting so the user can change this.

[bartekgorny]

On Mon, 12 Sep 2011 07:07:04 -0700
James Thompson
[email protected]
wrote:

I fixed this by doing the following:

models/events.py:
class Event(models.Model):
def _get_occurrence_list(self, start, end):

line 135:
occurrences.append(self._create_occurrence(o_start, o_end))
changed to:
occurrences.append(self.get_occurrence(o_start))

But I'm not sure if this breaks anything elsewhere... everything
worked in my project..

Did you run tests?

BG

Do you know, where your towel is?
(re: Hitchhikers Guide to the Galaxy)

[keiouu]

No new tests fail, I get 2 failed tests with HEAD but the change doesn't introduce any new failures.
The broken tests are testing for "orphaned" occurrences, however.. it is the "exception" occurrences that are tested.

As you said it is a design decision and one that I am not in a position to make, however, I do feel that exceptions to a rule are no longer part of that rule, as they would break it.

The main point of this change is as follows:

• Create a recurring event
• Modify one element
• Modify "all" of the other occurring events
  • in HEAD, a new occurrence will be created on top of the one you modified
  • with this change, no new occurrence will be created

edit - it seems this only fixes one side of the issue.. I'm working on a better fix now
the best thing I can think of is to use "sequences"

[keiouu]

Unfortunately in order to "properly" fix it, I ended up "updating" the start and end dates for occurrences:
keiouu@c17cb67

The tests all pass with the above commit but.. the solution isn't exactly ideal.. it works for my project though. I'll leave you to decide :)

Note: There is a print statement that wasn't meant to be there, sorry.