On Sun, 2019-12-08 at 16:00 +, Stephen Finucane wrote:
> This reduces a lot of the tech debt we had built up around this. This
> field is populated from a slugified representation of State.name and has
> a uniqueness constraint. As a result, we also need to a uniqueness
> constraint to the Stat
On 11/12/19 2:32 am, Stephen Finucane wrote:
I think the migration can still fail without printing a helpful
exception message if two states have names that are different but still
slugify to the same thing?
Good point. I can fix this if we think it's worth it. Personally, I
think the uniquenes
On Tue, 2019-12-10 at 15:43 +1100, Andrew Donnellan wrote:
> On 9/12/19 3:00 am, Stephen Finucane wrote:
> > --- /dev/null
> > +++ b/patchwork/migrations/0038_state_slug.py
> > @@ -0,0 +1,68 @@
> > +# -*- coding: utf-8 -*-
> > +
> > +from __future__ import unicode_literals
> > +
> > +from django.db
On 9/12/19 3:00 am, Stephen Finucane wrote:
--- /dev/null
+++ b/patchwork/migrations/0038_state_slug.py
@@ -0,0 +1,68 @@
+# -*- coding: utf-8 -*-
+
+from __future__ import unicode_literals
+
+from django.db import migrations, models, transaction
+from django.utils.text import slugify
+
+
+def val
This reduces a lot of the tech debt we had built up around this. This
field is populated from a slugified representation of State.name and has
a uniqueness constraint. As a result, we also need to a uniqueness
constraint to the State.name field. This shouldn't be an issue and
probably should have b
