On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson <ovan...@gmail.com> wrote: >> It doesn't result in good table design and adds restrictions/complication >> to the ORM/migrations. > > Well, honestly, making all subfields always nullable (whether it is or not) > in order to support the composite field being potentially nullable doesn't > really result in good table design either. > >> Enforcing that both x and y have a value should be handled with a >> constraint and/or validators. > > There is _no_ problem that is better handled with validators than an > equivalent database constraint unless you assume that the framework is the > only client your database will ever have.
You'll likely need both. The database constraint is there to catch all errors, whether generated by the framework or some other client. The validator will supply nice user-facing error messages. This is how unique constraints work for example: there is a model validator that says "this value already exists in the database", but we also have database level constraint to make sure there is no way to store invalid values. >> -1 on silently changing the field definition. At best this would result in >> an unnecessary migration when the error is discovered. Django should error >> out with a message that the composite field definition is invalid. > > Changing the subfield definitions in the composite field constructor has to > be supported, there's no way of passing parameters to subfields if you > don't. What mistake is there to be found? Either you want the composite > field to be nullable or you don't. You're being explicit about it by passing > `null=True` into the field definition and it's a standard field parameter. If the user supplies the fields, then we don't want to change them silently. We could have checks framework error for incompatible settings however. If the field auto-creates the subfields, then it can alter them in any way it wishes. Making the composite field null only when all of its subfields are null seems the right behavior to me. Otherwise you'd have strange cases where .filter(money__amount=10) is true, but .filter(money__isnull=True) is also true for the same row. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/CALMtK1GCSfemy%2BN0HLPMbsovwgcSy%2BwEw6QF-%2BoZ-tfBCTSkUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
