zulip/tools/do-destroy-rebuild-database

#!/bin/sh -xe

psql -h localhost postgres zulip <<EOF
DROP DATABASE IF EXISTS zulip;
CREATE DATABASE zulip TEMPLATE zulip_base;
EOF

python manage.py syncdb --noinput
python manage.py migrate
python manage.py createcachetable third_party_api_results
python manage.py populate_db -n100 --threads=1
# Ensure that the local user's API key is synced from ~/.zuliprc
python manage.py sync_api_key
Adapt do-schema-change for Postgres (imported from commit 3ab9054d110acf379c8d1686acaf56a92b4f90da) 2012-12-14 23:38:19 +01:00			`#!/bin/sh -xe`
do-schema-change: Add comment about collation order consequences (imported from commit 19dc226e3af3ab6e6b17a35414617f2948d6de34) 2012-10-30 21:11:37 +01:00
Persist the tsearch_extras extension across rebuilding of the database We do this by creating a new zulip{_test}_base database that only has the zulip schema and the tsearch_extras extension. We then use that as a template when creating zulip{_test}. (imported from commit 8adb4b98410e4042a0187902e89c99561eac8c8f) 2014-01-30 23:40:37 +01:00			`psql -h localhost postgres zulip <<EOF`
			`DROP DATABASE IF EXISTS zulip;`
			`CREATE DATABASE zulip TEMPLATE zulip_base;`
			`EOF`
do-schema-change: Add comment about collation order consequences (imported from commit 19dc226e3af3ab6e6b17a35414617f2948d6de34) 2012-10-30 21:11:37 +01:00
[manual] Excise South migrations prior to the User merge. South doesn't properly deal with removing the Django User model, so this commit redoes our South history to instead start after that migration has already been applied. This allows us to get rid of some annoying hacks. Note that developers and staging will need to run ./manage.py migrate --delete-ghost-migrations zephyr in order to clear out the old versions of the migrations. (imported from commit 7f45ea601b809dde33720f76e7dfb0ab348b0e65) 2013-05-06 18:24:47 +02:00			`python manage.py syncdb --noinput`
do-destroy-rebuild-database: Update for South. (imported from commit f3e5d62aa2be0fd907a24fb9b4a5be6438e76c8d) 2013-02-22 23:51:08 +01:00			`python manage.py migrate`
[manual] Cache results of the Twitter API in the database. This should substantially improve the repeat-rendering time for pages with large numbers of tweets since we don't need to go all the way to twitter.com, which can take like a second, to render tweets properly. To deploy this commit properly, one needs to run ./manage.py createcachetable third_party_api_results (imported from commit 01b528e61f9dde2ee718bdec0490088907b6017e) 2013-03-11 16:23:34 +01:00			`python manage.py createcachetable third_party_api_results`
do-destroy-rebuild-database: Default to randomly generated message data. And use only 1 thread, to work around pylibmc multithreading issues on OSX. (imported from commit bb065b611cb67133f727747cec4a0ff568513788) 2013-07-08 17:51:49 +02:00			`python manage.py populate_db -n100 --threads=1`
Rename ~/.humbugrc to ~/.zuliprc. (imported from commit a0d53dd20097a56971874dc1d84c6f95267e84f2) 2013-08-07 17:36:46 +02:00			`# Ensure that the local user's API key is synced from ~/.zuliprc`
Ensure your dev environment API key matches your ~/.humbugrc. (imported from commit d4d0699ce912685ede445ed677c46dfeefa68b42) 2013-05-29 17:39:10 +02:00			`python manage.py sync_api_key`