All the null handling stuff has been removed from the specification and replaced with slightly more stringent restrictions on `value_to_dict`. There is an updated version which includes that change, plus a couple more alterations that were discussed here and on the PR available here. <https://github.com/django/deps/pull/12>
Thomas On 9 March 2015 at 17:43, Anssi Kääriäinen <akaar...@gmail.com> wrote: > 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. > -- 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/CA%2Bm8oA_wa-CvNsKe5W_5bAWLtyHBQfTa77RDNYfg8kOfLM9kvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
