With regards to the field API - that probably doesn't need an ML discussion. Open a ticket on Trac, submit a PR, and the people that will want to see it will review it. If there's confusion about how to proceed, then an ML discussion can be had, when there are actually interested parties involved. I imagine Russ and Piros (if he's still kicking around, I think he is) will have some comments once there's something concrete to review.
2 cents On Thursday, 5 March 2015 13:59:44 UTC+11, Thomas Stephenson wrote: > > Hey there, > > Yeah, I've looked through some (probably not all) of the previous > proposals to support composite fields. I was going to wait until some more > work had been done to split concrete fields from virtual fields (ticket > 16508 <https://code.djangoproject.com/ticket/16508>), because I thought > that would be an ORM change that would have drastically simplified things, > but in the end I've found that I was able to keep the implementation > contained without it. > > Sorry if I sounded impatient -- it was just a bit of humour to kickstart > the conversation, since my previous thread (about a couple of small changes > to the field API I'd like to make to support this proposal) had been > languishing for four days without a single response. > > Thomas > > On 5 March 2015 at 11:52, Curtis Maloney <cur...@acommoncreative.com > <javascript:>> wrote: > >> Have you reviewed all the existing works on trying to add composite >> fields? >> >> I know several managed to reach a level of maturity that was almost merge >> quality, and am sure I heard some of the recent ORM changes would ease >> support. >> >> On 5 March 2015 at 11:42, Thomas Stephenson <ova...@gmail.com >> <javascript:>> wrote: >> >>> OK, no need for everyone to shout -- your message is heard loud and >>> clear. I'll go and find something else to work on. >>> >>> >> Wow... impatient much? Not everyone works in your timezone, or to your >> schedule. I, for one, was planning to take some time to review your >> proposal carefully, instead of "first thing in the morning whilst still >> having my coffee", as I feel it's a topic that deserves careful >> consideration. >> >> Don't you think it's worth giving everyone a chance to read your email >> before you give up and move on? It's only been 11 hours. Many of us were >> asleep for most of that. >> >> -- >> Curtis >> >> >> >>> On 5 March 2015 at 00:16, Thomas Stephenson <ova...@gmail.com >>> <javascript:>> wrote: >>> > Considering the past two proposals I've made here, I doubt I'll get >>> more >>> > than an echo chamber effect on this one. >>> > >>> > For the past week or so I've spent a bit of time on a feature I've >>> always >>> > wanted to see land in django -- composite fields. The tickets have >>> been open >>> > in the bug tracker for quite some time (and there's a few related >>> ones, such >>> > as multi-column primary keys that can all be killed with the one >>> stone). >>> > >>> > The work is available on this branch of my fork of django for the >>> moment -- >>> > I haven't opened up a PR yet because there's still some features that >>> are >>> > still to be implemented that will be explained below, but I want to >>> give >>> > everybody a chance to tell me where I can stick it before I spend >>> *too* much >>> > time on it. >>> > >>> > So, without further ado, the proposal. >>> > >>> > >>> > Composite Fields - Implemented >>> > >>> > A composite field is an encapsulation of the functionality of a subset >>> of >>> > fields on a model. Composite fields can be defined in one of two ways: >>> > >>> > 1. Statically declared composite fields >>> > >>> > A statically declared composite field is defined in the same way a >>> django >>> > model is defined. There are two customisable transformation functions, >>> > CompositeField.value_to_dict(self, value) and >>> > CompositeField.value_from_dict(self, value) which can be used to >>> associate >>> > the field with a python object. >>> > >>> > All the serialization functions are implemented via the >>> implementations of >>> > the subfields. >>> > >>> > For example, >>> > >>> > class MoneyField(models.CompositeField): >>> > currency_code = models.CharacterField(max_length=3) >>> > amount = models.DecimalField(max_digits=16, decimal_digits=4) >>> > >>> > ## Overriding __init__ can be used to pass field parameters to the >>> > subfields >>> > >>> > def value_from_dict(self, value): >>> > if value is None: >>> > return None >>> > return Money(**value) >>> > >>> > def value_to_dict(self, value): >>> > if value is None: >>> > return None >>> > return {attr: getattr(value, attr) for attr in ('currency_code', >>> > 'amount')} >>> > >>> > 2. Inline composite fields. >>> > >>> > An inline composite field is declared at the field definition site on >>> the >>> > body of a model, by providing the subfields as the 'fields' argument >>> of the >>> > CompositeField constructor. There are no transformation parameters >>> available >>> > to override when declaring a composite field in this fashion -- the >>> value of >>> > the field is always available as a python `dict` as an attribute on the >>> > MyModel >>> > >>> > class MyModel(models.Model): >>> > id = models.CompositeField(fields = [ >>> > ('a', models.IntegerField()), >>> > ('b', models.CharField(max_length=30) >>> > ], primary_key=True) >>> > >>> > This method for defining composite fields has a few drawbacks, but can >>> be >>> > useful if the only reason to add the composite field to the model was >>> to >>> > implement a unique_together or index_together constraint * >>> > >>> > * Although it's still possible to do that directly on class Meta. >>> > >>> > 3. Null >>> > >>> > Setting the value of a multi-column field to NULL is different than >>> setting >>> > any of the individual subfields to NULL. But there are cases (e.g. >>> Money) >>> > where we would like to be able to set `null=True` on a composite >>> field, but >>> > still retain 'NOT NULL' constraints on each of the subfield columns. >>> > >>> > To solve this problem, every table which implements a CompositeField >>> will >>> > also add an implicit (semi-hidden) `isnull` subfield on the attribute, >>> which >>> > keeps track of whether it is the value of the composite field that is >>> null, >>> > or any of the particular subfields. >>> > >>> > 3. Querying. >>> > >>> > The syntax for querying over the subfields of a composite field will be >>> > familiar to anyone who has queried over a relationship attribute in >>> django. >>> > >>> > model.objects.filter(price__currency_code='USD', >>> > price__amount__lt=Decimal('50.00')).all() >>> > >>> > In addition, composite fields can be queried via EXACT and IN lookups. >>> It is >>> > possible to implement custom lookups for specific statically defined >>> fields, >>> > but not recommended and not part of the official API. >>> > >>> > 4. Restrictions >>> > >>> > The following restrictions are currently imposed on the use of >>> composite >>> > fields. None of these are restrictions that can't be worked around in >>> future >>> > extensions, but they're restrictions which considerably simplify both >>> the >>> > implementation and API. >>> > >>> > - No related fields as a subfield of a composite field >>> > - No nested composite fields >>> > - No inheritance of composite fields (apart from inheriting from >>> > CompositeField itself). >>> > >>> > 5. Changes to the Field API >>> > >>> > As discussed in the other thread I posted. I've changed the >>> implementation >>> > so that _get_cache_name can still be dependent on the name, but I think >>> > using attname is more useful anyway. >>> > >>> > Composite Fields -- unimplemented >>> > >>> > These features are still not implemented >>> > >>> > - multi column primary keys. unique_together and index_together are >>> > implemented and adding a primary key constraint should be a similar >>> > operation. >>> > - some small issues with multi-table inheritance. >>> > - more test coverage >>> > - proper documentation >>> > - anything that comes out of this thread. >>> > >>> > >>> > >>> > >>> > -- >>> > 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-develop...@googlegroups.com <javascript:>. >>> > To post to this group, send email to django-d...@googlegroups.com >>> <javascript:>. >>> > 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/ed326cce-6784-429b-869b-f6f66d3c77fd%40googlegroups.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-develop...@googlegroups.com <javascript:>. >>> To post to this group, send email to django-d...@googlegroups.com >>> <javascript:>. >>> 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-hGgjDQhpQvL9%2Bk18VEjdeUf%3D8tNu1hsek%3Dp2nkEUzrA%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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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/CAG_XiSAK0eJOkSw_ENVRc0SUiNc1LrTEnk%3DZqcf8eJL%3DD4KbTw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAG_XiSAK0eJOkSw_ENVRc0SUiNc1LrTEnk%3DZqcf8eJL%3DD4KbTw%40mail.gmail.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 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/464cb3e1-6cb5-4057-9035-f57d9693f5bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
