table or look at
startup-time logging in error.log to see your current version.
-dre
>
> From: Axel Rau
> Sent: 20-Dec-2016 4:30 PM
> To: amaramra...@users.sourceforge.net
> Cc: calendarserver-dev@lists.macosforge.org; d...@apple.com
> Subject: Re: [CalendarServer-dev] Calenda
et
Cc: calendarserver-dev@lists.macosforge.org; d...@apple.com
Subject: Re: [CalendarServer-dev] Calendarserver 7.x compatibility with
sqlparse 0.2.2
> Am 20.12.2016 um 04:22 schrieb amaramra...@users.sourceforge.net:
>
> Ouch. So that essentially means that as a Debian package maintainer, eithe
> Am 20.12.2016 um 04:22 schrieb amaramra...@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
Server-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 o
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
