Add multiple-Obits-to-one-Death-Notice model functionality

[jheasly]

The ability to create several Obits off of one Death Notice has been requested. (As many as six Obits have been run based on one Death Notice.)

[jheasly]

To test this major database relationship change, I'll need to:

• [ ] Recreate the database locally.
• [ ] Replicate the changeover locally.
• [ ] Do it on the live server.

Had PostgreSQL 9.3.2 installed locally and 9.1.6 is what's intalled on projects.registerguard.com, so I nuked the local 9.3.2 and homebrew installed 9.1.11, the closest match I could get from the homebrew versions collection (https://github.com/Homebrew/homebrew-versions).

internet02:~ jheasly$ brew tap homebrew/versions
Cloning into '/usr/local/Library/Taps/homebrew-versions'...
remote: Reusing existing pack: 1590, done.
remote: Total 1590 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1590/1590), 515.78 KiB | 440 KiB/s, done.
Resolving deltas: 100% (821/821), done.
Tapped 127 formula
internet02:~ jheasly$ brew install postgresql91
==> Downloading http://ftp.postgresql.org/pub/source/v9.1.11/postgresql-9.1.11.tar.bz2
######################################################################## 100.0%
==> Patching
patching file src/pl/plpython/Makefile
patching file contrib/uuid-ossp/uuid-ossp.c
==> ./configure --prefix=/usr/local/Cellar/postgresql91/9.1.11 --datadir=/usr/local/Cellar/postgresql91/9.1.11/share/postgres
==> make install-world
==> Caveats
    # Build Notes

    If builds of PostgreSQL 9 are failing and you have version 8.x installed,
    you may need to remove the previous version first. See:
      https://github.com/mxcl/homebrew/issues/issue/2510

    To build plpython against a specific Python, set PYTHON prior to brewing:
      PYTHON=/usr/local/bin/python  brew install postgresql
    See:
      http://www.postgresql.org/docs/9.1/static/install-procedure.html

    # Create/Upgrade a Database

    If this is your first install, create a database with:
      initdb /usr/local/var/postgres -E utf8

    To migrate existing data from a previous major version (pre-9.1) of PostgreSQL, see:
      http://www.postgresql.org/docs/9.1/static/upgrading.html

    # Loading Extensions

    By default, Homebrew builds all available Contrib extensions.  To see a list of all
    available extensions, from the psql command line, run:
      SELECT * FROM pg_available_extensions;

    To load any of the extension names, navigate to the desired database and run:
      CREATE EXTENSION [extension name];

    For instance, to load the tablefunc extension in the current database, run:
      CREATE EXTENSION tablefunc;

    For more information on the CREATE EXTENSION command, see:
      http://www.postgresql.org/docs/9.1/static/sql-createextension.html
    For more information on extensions, see:
      http://www.postgresql.org/docs/9.1/static/contrib.html

    # Other

    Some machines may require provisioning of shared memory:
      http://www.postgresql.org/docs/current/static/kernel-resources.html#SYSVIPC
When installing the postgres gem, including ARCHFLAGS is recommended:
  ARCHFLAGS="-arch x86_64" gem install pg

To install gems without sudo, see the Homebrew wiki.

To have launchd start postgresql91 at login:
    ln -sfv /usr/local/opt/postgresql91/*.plist ~/Library/LaunchAgents
Then to load postgresql91 now:
    launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql91.plist
Or, if you don't want/need launchctl, you can just run:
    pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
==> Summary
/usr/local/Cellar/postgresql91/9.1.11: 2780 files, 37M, built in 6.3 minutes
internet02:~ jheasly$

---

Deleted old database (/usr/local/var/postgres):

initdb: directory "/usr/local/var/postgres" exists but is not empty If you want to create a new database system, either remove or empty the directory "/usr/local/var/postgres" or run initdb

... and started a brand new one:

---

internet02:~ jheasly$ initdb /usr/local/var/postgres -E utf8
The files belonging to this database system will be owned by user "jheasly".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default text search configuration will be set to "english".

fixing permissions on existing directory /usr/local/var/postgres ... ok
creating subdirectories ... ok
selecting default max_connections ... 20
selecting default shared_buffers ... 1600kB
creating configuration files ... ok
creating template1 database in /usr/local/var/postgres/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating collations ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
loading PL/pgSQL server-side language ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres
or
    pg_ctl -D /usr/local/var/postgres -l logfile start

internet02:~ jheasly$ 

Trying to get a homebrew 9.1.11 PostgreSQL installed locally to match 9.1.6 on projects.registerguard.com.

Issue: From /usr/local/var/postgres/server.log:

FATAL: database files are incompatible with server DETAIL: The database cluster was initialized with PG_CONTROL_VERSION 937, but the server was compiled with PG_CONTROL_VERSION 903. HINT: It looks like you need to initdb.

• [x] DELETE & RE-INSTALL 9.1.4 ON FRIDAY.

[jheasly]

1. dumpdata all of django_obit_desk2 app into .json file
2. Change from

    death_notice = models.OneToOneField(Death_notice, primary_key=True, limit_choices_to ={'death_notice_created__gte': datetime.datetime.now() - datetime.timedelta(days=DISPLAY_DAYS_BACK) })

... to ...

    death_notice = models.ForeignKey(Death_notice, primary_key=True, limit_choices_to ={'death_notice_created__gte': datetime.datetime.now() - datetime.timedelta(days=DISPLAY_DAYS_BACK) })

1. Then ...

projects=> begin;
BEGIN
projects=> DROP TABLE "django_obit_desk2_obituary";
DROP TABLE
projects=> DROP TABLE "django_obit_desk2_deathnoticeotherservices";
DROP TABLE
projects=> DROP TABLE "django_obit_desk2_service";
DROP TABLE
projects=> DROP TABLE "django_obit_desk2_death_notice";
DROP TABLE
projects=> DROP TABLE "django_obit_desk2_funeralhomeprofile";
DROP TABLE
projects=> DROP TABLE "django_obit_desk2_classifiedrep";
DROP TABLE
projects=> commit;
COMMIT
projects=> \q
(test_root)internet02:test_root jheasly$ python manage.py syncdb
Creating tables ...
Creating table django_obit_desk2_classifiedrep
Creating table django_obit_desk2_funeralhomeprofile
Creating table django_obit_desk2_death_notice
Creating table django_obit_desk2_service
Creating table django_obit_desk2_deathnoticeotherservices
Creating table django_obit_desk2_obituary
The following content types are stale and need to be deleted:

    ap_wfm | category

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: no
Installing custom SQL ...
Installing indexes ...
No fixtures found.
(test_root)internet02:test_root jheasly$ python manage.py loaddata ../django_obit_desk2/fixtures/django_obit_desk2.json 

[jheasly]

I think this

CONSTRAINT django_obit_desk2_obituary_pkey PRIMARY KEY (death_notice_id),
  CONSTRAINT django_obit_desk2_obituary_death_notice_id_fkey FOREIGN KEY (death_notice_id)
      REFERENCES django_obit_desk2_death_notice (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,
  CONSTRAINT django_obit_desk2_obituary_user_id_fkey FOREIGN KEY (user_id)
      REFERENCES auth_user (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED

... is the cause of this ...

So, let's dump the Obituary data, redefine the model without the Death Notice id bit.

[jheasly]

Successfully manually fixed a fixture file:

• [ ] Fix fixture for all 3,000 + Obituaries

Now, need to add a second Obituary to a Death Notice via Admin:

• [x] It worked!
• [ ] Add a second Obituary via FH frontend.

[jheasly]

Wendy Carole Shaw is testing ...

[jheasly]

The search-and-replace regex to add/patch the death_notice: \d\d\d\d, bit to the obituary fixture file:

^(    "pk": )(\d?\d)(, \n    "model": "django_obit_desk2\.obituary", \n    "fields": {\n)

\1\2\3      "death_notice": \2, \n

Basically the above adds the "death_notice": [id] bit mentioned two comments up.

[jheasly]

Wendy C.'s been testing, says it's good to go, but she's out Monday, Feb. 17, so we'll cut it over Tuesday, Feb. 18
Also, Wendy R.'s going to provide some better character counts for the 2-column, 2-photo obits: "Evidently they aren't as accurate as they need to be ;-)"

[jheasly]

Cutover steps. (Thinking out loud here):

6 p.m.: Obituary count before: 944 Death_notice count before: 3,473

On live server:

1. .json data dump
2. Make a copy and do the data transformation via regex (see two entries up above).
3. Delete django_obit_desk2.obituary table via modified result of python manage.py sqlclear django_obit_desk2
4. On live server, git pull latest commit: https://github.com/jheasly/django_obit_desk2/commit/f2641e357ff4859c0dad0abbc353034f591eef91

BEGIN;
DROP TABLE "django_obit_desk2_obituary";
COMMIT;

1. python manage.py syncdb
2. loaddata fixed fixture
3. touch apache/django.wsgi
4. Check stuff out ...

[jheasly]

Done. Wendy C. and Wendy R. notified.