On Wednesday, April 2, 2014 3:35:24 AM UTC+10:30, Andrew Godwin wrote:
>
> Hmm, I'm not sure about this. On the one hand, during the migrations work
> I refactored check constraints for the existing stuff (e.g.
> PostitiveIntegerField) out of the type string and into a separate check
> constraints string, so some of the work is already there, especially around
> making sure they're present on field alteration.
>
> On the other hand, check constraints vary wildly from database to database
> - MySQL doesn't have them, SQLite has a basic version in later versions
> only and parses but ignores them in earlier versions, PostgreSQL has full
> support and Oracle has them too but with a different set of functions to
> PostgreSQL, so it's unlikely anything other than simple comparison would be
> portable.
>
Thanks Andrew. I haven't touched other databases for a long time, so it's
good to get that feedback.
> For that reason, I wouldn't be the fan of the exploded syntax you've
> given; I think I'd rather just be able to supply a list of strings for my
> constraints that are SQL themselves; there's no real benefit to abstraction
> here, and removing it doubtless removes a lot of code and bugs. Otherwise,
> I think I'd be +0.
>
Pushing on from there: it's not much work from doing "constraints = ('check
start < finish',)" to just writing a RunSQL migration operation. The
exploded syntax was more me working things through late at night anyway.
And it seems like there's not really much else to do other than raw SQL for
exclude constraints.
So, it's actually possible to do _most_ of what I want already - just using
a migration. The per-field check constraint could/should also be
implemented as a validator. Exclude constraints are another kettle of fish:
as I mentioned before, it's not actually possible to validate these
constraints without hitting the database, and even then that's not alway
enough. You still need to handle IntegrityErrors if an update between when
you checked and when you actually try to save causes a conflict.
Matt.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/378962de-7ae6-496e-8a85-88c964d43e78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
