def test_migrateMergeCalendars(self): """ Migrating a home with a conflicting (non-default) calendar in merge mode will cause the properties on the conflicting calendar to be overridden by the new calendar of the same name, and calendar objects to be copied over. """ yield self.createConflicted() from txdav.base.propertystore.base import PropertyName from txdav.xml import element as davxml class StubConflictingElement(davxml.WebDAVTextElement): namespace = "http://example.com/ns/stub-conflict" name = "conflict" beforeProp = StubConflictingElement.fromString("before") afterProp = StubConflictingElement.fromString("after") conflictPropName = PropertyName.fromElement(beforeProp) txn = self.transactionUnderTest() conflict1 = yield txn.calendarHomeWithUID("conflict1") conflict2 = yield txn.calendarHomeWithUID("conflict2") cal1 = yield conflict1.calendarWithName("conflicted") cal2 = yield conflict2.calendarWithName("conflicted") p1 = cal1.properties() p2 = cal2.properties() p1[conflictPropName] = afterProp p2[conflictPropName] = beforeProp yield migrateHome(conflict1, conflict2, merge=True) self.assertEquals(p2[conflictPropName].children[0].data, "after") obj1 = yield cal2.calendarObjectWithName("1.ics") obj2 = yield cal2.calendarObjectWithName("2.ics") # just a really cursory check to make sure they're really there. self.assertEquals(obj1.uid(), "uid1") self.assertEquals(obj2.uid(), "uid2")
def test_migrateEmptyHome(self): """ Migrating an empty home into an existing home should destroy all the existing home's calendars. """ yield populateCalendarsFrom({ "empty_home": { # Some of the upgrade logic will ensure that sufficient default # calendars exist for basic usage, so this home is actually only # *mostly* empty; the important thing is that the default # calendar is removed. "other-default-calendar": {} }, "non_empty_home": { "calendar": {}, "inbox": {}, # XXX: implementation is configuration-sensitive regarding the # 'tasks' calendar and it shouldn't be. "tasks": {}, "polls": {}, } }, self.storeUnderTest()) txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") self.assertIdentical((yield emptyHome.calendarWithName("calendar")), None) nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") yield migrateHome(emptyHome, nonEmpty) yield self.commit() txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") self.assertIdentical((yield nonEmpty.calendarWithName("calendar")), None) self.assertNotIdentical((yield nonEmpty.calendarWithName("inbox")), None) self.assertNotIdentical((yield nonEmpty.calendarWithName("other-default-calendar")), None)
def test_migrateConflict(self): """ Migrating a home with conflicting (non-default) calendars will cause an error. """ yield self.createConflicted() txn = self.transactionUnderTest() conflict1 = yield txn.calendarHomeWithUID("conflict1") conflict2 = yield txn.calendarHomeWithUID("conflict2") try: yield migrateHome(conflict1, conflict2) except HomeChildNameAlreadyExistsError: pass else: self.fail("No exception raised.")
def test_migrateMergeDontDeleteDefault(self): """ If we're doing a merge migration, it's quite possible that the user has scheduled events onto their default calendar already. In fact the whole point of a merge migration is to preserve data that might have been created there. So, let's make sure that we I{don't} delete any data from the default calendars in the case that we're merging. """ yield populateCalendarsFrom( { "empty_home": { # see test_migrateEmptyHome above. "other-default-calendar": {} }, "non_empty_home": { "calendar": { "some-name": self.sampleEvent("some-uid", "some summary"), }, "inbox": {}, "tasks": {} } }, self.storeUnderTest()) txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") self.assertIdentical((yield emptyHome.calendarWithName("calendar")), None) nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") yield migrateHome(emptyHome, nonEmpty, merge=True) yield self.commit() txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") self.assertNotIdentical((yield nonEmpty.calendarWithName("inbox")), None) defaultCal = (yield nonEmpty.calendarWithName("calendar")) self.assertNotIdentical( (yield defaultCal.calendarObjectWithName("some-name")), None)
def test_migrateMergeDontDeleteDefault(self): """ If we're doing a merge migration, it's quite possible that the user has scheduled events onto their default calendar already. In fact the whole point of a merge migration is to preserve data that might have been created there. So, let's make sure that we I{don't} delete any data from the default calendars in the case that we're merging. """ yield populateCalendarsFrom({ "empty_home": { # see test_migrateEmptyHome above. "other-default-calendar": {} }, "non_empty_home": { "calendar": { "some-name": self.sampleEvent("some-uid", "some summary"), }, "inbox": {}, "tasks": {} } }, self.storeUnderTest()) txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") self.assertIdentical((yield emptyHome.calendarWithName("calendar")), None) nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") yield migrateHome(emptyHome, nonEmpty, merge=True) yield self.commit() txn = self.transactionUnderTest() emptyHome = yield txn.calendarHomeWithUID("empty_home") nonEmpty = yield txn.calendarHomeWithUID("non_empty_home") self.assertNotIdentical( (yield nonEmpty.calendarWithName("inbox")), None ) defaultCal = (yield nonEmpty.calendarWithName("calendar")) self.assertNotIdentical( (yield defaultCal.calendarObjectWithName("some-name")), None )
def test_migrateMergeConflictingObjects(self): """ When merging two homes together, calendar objects may conflict in the following ways: First, an object may have the same name and the same UID as an object in the target calendar. We assume the target object is always be newer than the source object, so this type of conflict will leave the source object unmodified. This type of conflict is expected, and may happen as a result of an implicitly scheduled event where the principal owning the merged calendars is an attendee of the conflicting object, and received a re-invitation. Second, an object may have a different name, but the same UID as an object in the target calendar. While this type of conflict is not expected -- most clients will choose names for objects that correspond to the iCalendar UIDs of their main component -- it is treated the same way as the first conflict. Third, an object may have the same UID as an object on a different calendar in the target home. This may also happen if a scheduled event was previously on a different (most likely non-default) calendar. Technically this is actually valid, and it is possible to have the same object in multiple calendars as long as the object is not scheduled; however, that type of conflict is extremely unlikely as the client would have to generate the same event twice. Basically, in all expected cases, conflicts will only occur because an update to a scheduled event was sent out and the target home accepted it. Therefore, conflicts are always resolved in favor of ignoring the source data and trusting that the target data is more reliable. """ # Note: these tests are all performed with un-scheduled data because it # is simpler. Although the expected conflicts will involve scheduled # data the behavior will be exactly the same. yield self.createConflicted( { "same-name": self.sampleEvent("same-name", "source"), "other-name": self.sampleEvent("other-uid", "source other"), "other-calendar": self.sampleEvent("oc", "source calendar"), "no-conflict": self.sampleEvent("no-conflict", "okay"), }, { "same-name": self.sampleEvent("same-name", "target"), "different-name": self.sampleEvent("other-uid", "tgt other"), }, ) txn = self.transactionUnderTest() c2 = yield txn.calendarHomeWithUID("conflict2") otherCal = yield c2.createCalendarWithName("othercal") yield otherCal.createCalendarObjectWithName( "some-name", Component.fromString(self.sampleEvent("oc", "target calendar")[0])) yield self.commit() txn = self.transactionUnderTest() c1 = yield txn.calendarHomeWithUID("conflict1") c2 = yield txn.calendarHomeWithUID("conflict2") yield migrateHome(c1, c2, merge=True) yield self.commit() txn = self.transactionUnderTest() c2 = yield txn.calendarHomeWithUID("conflict2") targetCal = yield c2.calendarWithName("conflicted") yield self.checkSummary("same-name", "target", targetCal) yield self.checkSummary("different-name", "tgt other", targetCal) yield self.checkSummary("other-calendar", None, targetCal) yield self.checkSummary("other-name", None, targetCal) yield self.checkSummary("no-conflict", "okay", targetCal) yield self.checkSummary("oc", "target calendar", otherCal)
def test_migrateMergeConflictingObjects(self): """ When merging two homes together, calendar objects may conflict in the following ways: First, an object may have the same name and the same UID as an object in the target calendar. We assume the target object is always be newer than the source object, so this type of conflict will leave the source object unmodified. This type of conflict is expected, and may happen as a result of an implicitly scheduled event where the principal owning the merged calendars is an attendee of the conflicting object, and received a re-invitation. Second, an object may have a different name, but the same UID as an object in the target calendar. While this type of conflict is not expected -- most clients will choose names for objects that correspond to the iCalendar UIDs of their main component -- it is treated the same way as the first conflict. Third, an object may have the same UID as an object on a different calendar in the target home. This may also happen if a scheduled event was previously on a different (most likely non-default) calendar. Technically this is actually valid, and it is possible to have the same object in multiple calendars as long as the object is not scheduled; however, that type of conflict is extremely unlikely as the client would have to generate the same event twice. Basically, in all expected cases, conflicts will only occur because an update to a scheduled event was sent out and the target home accepted it. Therefore, conflicts are always resolved in favor of ignoring the source data and trusting that the target data is more reliable. """ # Note: these tests are all performed with un-scheduled data because it # is simpler. Although the expected conflicts will involve scheduled # data the behavior will be exactly the same. yield self.createConflicted( { "same-name": self.sampleEvent("same-name", "source"), "other-name": self.sampleEvent("other-uid", "source other"), "other-calendar": self.sampleEvent("oc", "source calendar"), "no-conflict": self.sampleEvent("no-conflict", "okay"), }, { "same-name": self.sampleEvent("same-name", "target"), "different-name": self.sampleEvent("other-uid", "tgt other"), }, ) txn = self.transactionUnderTest() c2 = yield txn.calendarHomeWithUID("conflict2") otherCal = yield c2.createCalendarWithName("othercal") yield otherCal.createCalendarObjectWithName( "some-name", Component.fromString( self.sampleEvent("oc", "target calendar")[0] ) ) yield self.commit() txn = self.transactionUnderTest() c1 = yield txn.calendarHomeWithUID("conflict1") c2 = yield txn.calendarHomeWithUID("conflict2") yield migrateHome(c1, c2, merge=True) yield self.commit() txn = self.transactionUnderTest() c2 = yield txn.calendarHomeWithUID("conflict2") targetCal = yield c2.calendarWithName("conflicted") yield self.checkSummary("same-name", "target", targetCal) yield self.checkSummary("different-name", "tgt other", targetCal) yield self.checkSummary("other-calendar", None, targetCal) yield self.checkSummary("other-name", None, targetCal) yield self.checkSummary("no-conflict", "okay", targetCal) yield self.checkSummary("oc", "target calendar", otherCal)