IRC discussion sounds fine with me, but I'd like to be involved. What's the channel?
Thomas On 18 March 2015 at 15:47, Asif Saifuddin <[email protected]> wrote: > but? IRC discussion? > > On Tuesday, March 17, 2015 at 9:09:49 PM UTC+6, Thomas Stephenson wrote: >> >> Not impatient or anything, but... >> >> Bump. >> >> On 13 March 2015 at 14:07, Thomas Stephenson <[email protected]> wrote: >> >>> 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 <[email protected]> wrote: >>> >>>> On Mon, Mar 9, 2015 at 8:06 AM, Thomas Stephenson <[email protected]> >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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/0f8b0979-7e15-45d2-ab76-88dc747a0bf7%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/0f8b0979-7e15-45d2-ab76-88dc747a0bf7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To post to this group, send email to [email protected]. 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_mryzSJtdp4mB7KZ%2BRJxVqAX-nE7tY-5tJ%3DORwyrx9Rg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
