[CalendarServer-dev] Error with Files backend in Debian Jessie
amaramrahul at users.sourceforge.net
Wed Mar 5 11:34:27 PST 2014
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.
> 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.
> -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:
> -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
> --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).
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?
More information about the calendarserver-dev