[CalendarServer-dev] Error with Files backend in Debian Jessie

[Rahul Amaram]

On Monday 18 November 2013 11:29 PM, Andre LaBranche wrote:
> On Nov 18, 2013, at 9:17 AM, Rahul Amaram <amaramrahul at users.sourceforge.net> wrote:
>> Any response to this? I am unable to push to the new version to Debian as I need more clarity with the migration process. Request the developers to help me out with this.
> Hi,
>
> When the server starts, if there is any calendar data in the DocumentRoot, that data will be upgraded and imported into the database. This is configured to happen automatically for Server.app; however for open source, please be aware of the following items, which are also useful for controlling how database schema updates are performed:
>
> * The caldavd.plist key FailIfUpgradeNeeded
>
> "FailIfUpgradeNeeded"  : True,
> # Set to True to prevent the server or utility tools
> # tools from running if the database needs a schema
> # upgrade.
>
> (and hey, looks like we have a typo... They are just tools, not tools tools :)
>
> The cli tool calendarserver_upgrade:
>
> andre at xomg[trunk/CalendarServer]./python bin/calendarserver_upgrade --help
> Usage: calendarserver_upgrade [options] [input specifiers]
>
> This tool allows any necessary upgrade to complete, then exits.
> Options:
>    -s, --status       Check database status and exit.
>    -p, --postprocess  Perform post-database-import processing.
>    -D, --debug        Debug logging.
>    -f, --config=      Specify caldavd.plist configuration path. [default:
>                       /Applications/Server.app/Contents/ServerRoot/private/etc/caldavd/caldavd-apple.plist]
>    -x, --prefix=      Only upgrade homes with the specified GUID prefix - partial
>                       upgrade only. [default: ]
>        --help         Display this help and exit.
>    -m, --merge        Rather than skipping homes that exist on the filesystem but
>                       not in the database, merge their data into the existing
>                       homes.
>        --version      Display Twisted version and exit.
>    -o, --output=      Specify output file path (default: '-', meaning stdout).
>
>
> Unless you set FailIfUpgradeNeeded to false, you need to run calendarserver_upgrade any time the server's schema and data version are newer than existing data (whether it's in the filesystem or the DB).
>
> -dre
This is a really old thread for which I needed a clarification. How do 
we perform database schema upgrade? Currently I am doing it manually by 
calling each of the upgrade_from_<from>_to_<to>.sql version files. Does 
calendarserver_upgrade take care of it? If not, is there an easier way 
of doing it?

Currently for upgrading from 3.2 files to 5.1 db backend, I am just 
creating a new db. And the migration from 3.2 files backend to 5.1 db 
seems to work fine. Is there anything else that I should take care?

Thanks,
Rahul.