[CalendarServer-changes] [5581] CalendarServer/branches/users/wsanchez/transations/twistedcaldav/ method/mkcalendar.py

source_changes at macosforge.org source_changes at macosforge.org
Sun May 9 15:54:58 PDT 2010


Revision: 5581
          http://trac.macosforge.org/projects/calendarserver/changeset/5581
Author:   glyph at apple.com
Date:     2010-05-09 15:54:56 -0700 (Sun, 09 May 2010)
Log Message:
-----------
Temporary fix; just enough transaction logic to get test_collectioncontents to pass.

Modified Paths:
--------------
    CalendarServer/branches/users/wsanchez/transations/twistedcaldav/method/mkcalendar.py

Modified: CalendarServer/branches/users/wsanchez/transations/twistedcaldav/method/mkcalendar.py
===================================================================
--- CalendarServer/branches/users/wsanchez/transations/twistedcaldav/method/mkcalendar.py	2010-05-09 22:52:58 UTC (rev 5580)
+++ CalendarServer/branches/users/wsanchez/transations/twistedcaldav/method/mkcalendar.py	2010-05-09 22:54:56 UTC (rev 5581)
@@ -110,4 +110,9 @@
             errors.error()
             raise HTTPError(MultiStatusResponse([errors.response()]))
 
+    # FIXME: this should really be handled by higher-level machinery.  Even
+    # forgetting the obvious abstraction violation, there's no clear way to
+    # ensure that the rollback will be called at all the appropriate times if
+    # it's the responsibility of each method.  A response-filter, maybe?
+    self._newStoreCalendar._transaction.commit()
     returnValue(responsecode.CREATED)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20100509/51fd1eb3/attachment.html>


More information about the calendarserver-changes mailing list