[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