Hi, I think there is a compatibility issue. In this case, it's because sqlparse added a bunch of "new" keywords (from oracle) that conflict with identifiers we already use. We got as far as trying to retroactively rewrite all our *past* schema updates to be compatible (by quoting table / column names) but iirc that brings us out of sync with all existing CalendarServer DBs. Fixing that correctly would be a significant undertaking, requiring a schema update to rename everything. I think there may be a more hacky option of customizing the sqlparse keyword list at runtime to remove the conflicting keywords, but we didn't do that. I think there may have also been a problem around not easily being able to make that customization early enough and at the right layer.
Related: https://lists.macosforge.org/pipermail/calendarserver-dev/2016-November/001799.html -dre > On Dec 18, 2016, at 6:50 AM, amaramra...@users.sourceforge.net wrote: > > This is regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848361 > > I need to look into this but before I begin to debug the issue, I just wanted > to do a quick check to see if there are any known compatibility issues of > calendarserver 7.x with sqlparse 0.2.2? If so, is there a patch / commit id > that I can backport? > > Sent from Nine > _______________________________________________ > calendarserver-dev mailing list > calendarserver-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
