migrate to Django 1.8

[jamesturk]

the pinned Django version is currently the RC of 1.7, with 1.8's release it is probably time to address that (if this takes longer than expected we should at least move to 1.7.7)

Right now I have a branch @ https://github.com/opencivicdata/python-opencivicdata-django/tree/django1.8

• fixes the loaddivisions command to use the new management command argparse-based framework
• migrates djorm_pgarray to the new django.contrib.postgres

Three outstanding questions on the ArrayField front:

• what does this do with an existing DB? do the fields still work (the migration had to be hand-edited)
• do we query the pgarray field anywhere?
• was adding blank=True the right thing to do on all ArrayFields? It looks like pgarray didn't check for blank but django.contrib.postgres does

[jamesturk]

@paultag latest commit tries to use 1.8 but doesn't make these changes

[paultag]

Ach, duh, right, we had a release of Django

[dcloud]

I'm implementing some filter adjustment things in imago that will query array fields, but I don't think the syntax is different between django.contrib.postgres and djorm_pgarray. At least field__contains=['foo'] and field__contained_by=['foo'] are the same.

And here is some unsolicited input:

I used ArrayField in a project and setdefault=[] so that I could assume I could iterate over an array and not need to check for null. I don't think ArrayField allows blank=True, so setting an empty default seemed like the best bet.

There is also a django.contrib.postgres UUIDField that could possibly replace uuidfield.UUIDField.

[jamesturk]

@paultag @boblannon

if we migrate off UUIDField and ArrayField I think we'd need to delete the migrations and start fresh, there's not a clean way to do this since the UUID is the PK. would that be problematic for either one or is now the time to do so?

migration to django's internal JSONfield would be a separate issue, still looking into that but I'd actually probably suggest dropping the existing JSONfield for now and then re-adding it when we have a working JSONB implementation.

[paultag]

Resetting the DB sounds OK; what's the underlying storage type of UUIDField
and the Django UUID stuff?

On Tue, May 19, 2015 at 12:31 PM, James Turk notifications@github.com
wrote:

@paultag https://github.com/paultag @boblannon
https://github.com/boblannon

if we migrate off UUIDField and ArrayField I think we'd need to delete the
migrations and start fresh, there's not a clean way to do this since the
UUID is the PK. would that be problematic for either one or is now the time
to do so.

migration to django's internal JSONfield would be a separate issue, still
looking into that but I'd actually probably suggest dropping the existing
JSONfield for now and then re-adding it when we have a working JSONB
implementation.

—
Reply to this email directly or view it on GitHub
#31 (comment)
.

Paul Tagliamonte
Software Developer | Sunlight Foundation

[jamesturk]

old was a varchar(32) new is the postgres UUID type

https://github.com/opencivicdata/python-opencivicdata-django/tree/django1.8-nouuid

[jamesturk]

thoughts on how we want to handle the JSON type?

[paultag]

Sounds like we'll have to rebuild the DB; might as well do it once --
howabout we trash, go full UUID, drop jsonfield totally, and switch to
jsonb? We might need a backport but I'm sure that we can find one

On Tue, May 19, 2015 at 1:24 PM, James Turk notifications@github.com
wrote:

thoughts on how we want to handle the JSON type?

—
Reply to this email directly or view it on GitHub
#31 (comment)
.

Paul Tagliamonte
Software Developer | Sunlight Foundation

[jamesturk]

ready for review in #42

[jamesturk]

one better, 0.7.x will go straight to 1.9