Feature/gcal integration #79
Conversation
…event, only after requested by the user.
…ngle quotes for the sake of consistency.
…ndar could in some cases come too close to the page bottom.
…per class to catch error (for example missing credentials file) instantly.
| def __init__(self, booking): | ||
| self.booking = booking | ||
| self.gcal = GoogleCalendar(booking.bookable.google_calendar_id) | ||
| Thread.__init__(self) |
There was a problem hiding this comment.
IIRC threads in python are kind of a "fake" implementation. There is no actual parallelism, just async execution. I guess this is still fine though, as long as the request is allowed to finish handling and return the response without having to wait for the thread to finish.
…GCal helper class to catch error (for example missing credentials file) instantly." This reverts commit 9c9f2c3.
- Changed Booking.save() parameter name to avoid having gcal logic in repeating bookings logic. - Changed GoogleCalendar helper class to mainly take event ids as method params. - Changed the GCal thread classes to work on GCalEvent objects.
There was a problem hiding this comment.
I'd be content with this implementation, but I think further improvements could be made.
For one, I think the gcal sync should happen inside the GCalEvent's save/delete methods. This way the sync will work as expected when working directly with GCalEvent objects.
The GCalEventThreads should then simply call the appropriate method on the GCalEvent model.
I think I'd even have the GCalEvent model lookup the Booking from the DB rather than passing a copy to the thread. This way the threads work more independently, with less risk of race conditions. It'll be a slightly higher load on the DB, but hardly an issue.
Added integration of Google Calendar to FARS. You can configure a Bookable to create gcal events for every new Booking.