# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations


def create_custom_finders(apps, schema_editor):
    CustomFinder = apps.get_model("pollingstations", "CustomFinder")

    CustomFinder.objects.update_or_create(
        area_code='N07000001',
        base_url='http://www.eoni.org.uk/'
                 + 'Offices/Postcode-Search-Results?postcode=',
        can_pass_postcode=True,
        message='The Electoral Office of Northern Ireland' +
                ' has its own polling station finder:',
    )


def remove_custom_finders(apps, schema_editor):
    CustomFinder = apps.get_model("pollingstations", "CustomFinder")
    CustomFinder.objects.filter(
        area_code__in=['N07000001', ]).delete()


class Migration(migrations.Migration):

    dependencies = [
        ('pollingstations', '0012_auto_20170211_1443'),
    ]

    operations = [
        migrations.RunPython(create_custom_finders, remove_custom_finders),
    ]

Add CustomFinders in data migrations
Add CustomFinders in data migrations

I'm not 100% sure this is the best way of doing this in the long term:

Good: CustomFinders are automatically added when migrations are run,
meaning we don't need to figure out a new system for importing them.

They are also checked in to version control, meaning we should have a
good idea of what's active on any deploy.

Bad: After some time we might add and remove lots of custom finders
meaning that we have loads of migrations adding and removing them
over the history of the app. This will slow everything down and
generally not be useful.

I'm going to stick with this for the time being though, as for the moment
we only have 2, and the EONI one is likely to be there for a long time.
