Remove special unique constraints ReducedDatums

[jchate6]

The unique constraints we used to use were necessary because validating on the "value" field wasn't possible. This is no longer the case.

[jchate6]

@Fingel Without these constraints, I think we need to add some check in the API loop to make sure we aren't ingesting identical data.

I'm not sure where that should be... serializers.ReducedDatumSerializer.create? models.try_parse_reduced_datum?

Maybe we just need to include more fields in the constraints, rather than remove them, but this feels like it can be solved by a get_or_create somewhere rather than a constraint, since we have actual known fields we can test against now.

Suggestions?

[Fingel]

I'm always going to prefer database constraints to (potentially) faulty business logic. A constraint doesn't prevent a get_or_create() from working either, they aren't mutually exclusive.

I think what actually happened here is the use case of duplicate reductions wasn't taken into account. I think Rachel was correct when she said that a version number should be tracked and added to the constraint, or alternatively one could use an upsert pattern to either update the incoming datum, or create a new one if it doesn't exist.

I don't think removing DB constraints entirely is a good idea.