Calendarserver 7.x compatibility with sqlparse 0.2.2
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
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
Ouch. So that essentially means that as a Debian package maintainer, either I'll have to package a compatible sqlparse version separate or wait for upstream to release a version that works with sqlparse 0.2.2. given the Debian release timeline, I believe the former is my only option in reality. Thanks for the response. I'll check with other Debian mentors and see what I can do. ________________________________ From: Andre LaBranche <dre@apple.com> Sent: 19-Dec-2016 11:15 PM To: amaramrahul@users.sourceforge.net Cc: calendarserver-dev@lists.macosforge.org Subject: Re: [CalendarServer-dev] Calendarserver 7.x compatibility with sqlparse 0.2.2 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
Am 20.12.2016 um 04:22 schrieb amaramrahul@users.sourceforge.net:
Ouch. So that essentially means that as a Debian package maintainer, either I'll have to package a compatible sqlparse version separate or wait for upstream to release a version that works with sqlparse 0.2.2. given the Debian release timeline, I believe the former is my only option in reality.
I did the same for the FreeBSD port, I maintain: http://www.freshports.org/www/calendarserver/ <http://www.freshports.org/www/calendarserver/> Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Even if I upgrade to 0.9, I think I'll still be facing the challenge of how to migrate the data from existing installations. Would I be right in this assumption of mine? ________________________________ From: Axel Rau <Axel.Rau@chaos1.de> Sent: 20-Dec-2016 4:30 PM To: amaramrahul@users.sourceforge.net Cc: calendarserver-dev@lists.macosforge.org; dre@apple.com Subject: Re: [CalendarServer-dev] Calendarserver 7.x compatibility with sqlparse 0.2.2
Am 20.12.2016 um 04:22 schrieb amaramrahul@users.sourceforge.net:
Ouch. So that essentially means that as a Debian package maintainer, either I'll have to package a compatible sqlparse version separate or wait for upstream to release a version that works with sqlparse 0.2.2. given the Debian release timeline, I believe the former is my only option in reality.
I did the same for the FreeBSD port, I maintain: http://www.freshports.org/www/calendarserver/ Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
On Dec 20, 2016, at 6:06 AM, amaramrahul@users.sourceforge.net wrote:
Even if I upgrade to 0.9, I think I'll still be facing the challenge of how to migrate the data from existing installations. Would I be right in this assumption of mine?
If you meant 9.0, as in CalendarServer 9.0, then the same rules apply here as for any CalendarServer upgrade: there may be a schema update required, so any time you update, be prepared for this possibility. You can tell if a DB upgrade would be required by looking at txdav/common/datastore/sql_schema/current.sql for a given branch / release, e.g.: https://github.com/apple/ccs-calendarserver/blob/master/txdav/common/datasto... <https://github.com/apple/ccs-calendarserver/blob/master/txdav/common/datastore/sql_schema/current.sql> At the bottom, you'll see something like: insert into CALENDARSERVER values ('VERSION', '65'); insert into CALENDARSERVER values ('CALENDAR-DATAVERSION', '6'); This means CalendarServer running that code would want schema version 65 and dataversion 6. You can check your DB's calendarserver table or look at startup-time logging in error.log to see your current version. -dre
From: Axel Rau <Axel.Rau@chaos1.de> Sent: 20-Dec-2016 4:30 PM To: amaramrahul@users.sourceforge.net Cc: calendarserver-dev@lists.macosforge.org; dre@apple.com Subject: Re: [CalendarServer-dev] Calendarserver 7.x compatibility with sqlparse 0.2.2
Am 20.12.2016 um 04:22 schrieb amaramrahul@users.sourceforge.net <mailto:amaramrahul@users.sourceforge.net>:
Ouch. So that essentially means that as a Debian package maintainer, either I'll have to package a compatible sqlparse version separate or wait for upstream to release a version that works with sqlparse 0.2.2. given the Debian release timeline, I believe the former is my only option in reality.
I did the same for the FreeBSD port, I maintain: http://www.freshports.org/www/calendarserver/ <http://www.freshports.org/www/calendarserver/>
Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
participants (3)
-
amaramrahul＠users.sourceforge.net
-
Andre LaBranche
-
Axel Rau