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/0017... -dre
On Dec 18, 2016, at 6:50 AM, amaramrahul@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