Hey Thomas, You've only waited 11 hours for a response here. Your contributions are definitely welcome, and it's obvious that you've done a lot of work and put in a lot of effort. Personally, I thank you.
The reason you're not getting a response, at this point, is because the number of people able to intelligently comment on your proposal is very small. I can think of a few people that would have some interest, including Ansii, Loic, and probably Marc. I'm interested in the ORM in general, but I really have no opinion on Composite Fields at the moment, so I have nothing to really offer you except some positive wishes. I know there is a desire to have composite fields and keys. The last brief discussion that I can find is here: https://groups.google.com/forum/#!searchin/django-developers/composite%7Csort:date/django-developers/ww6o-1kvI28/OE_V6e8qlWgJ which calls out a particular branch where work had already commenced. AFAIK, it's also a Google Summer of Code suggested project. So please, don't be disheartened. As I said, the number of users that could give you feedback is small, and there is a very cyclic pattern of activity amongst those developers. I would encourage you to read previous discussions and look at previous attempts, and continue with your work. It most definitely is wanted. Someone will be around, eventually, to offer help and guidance when needed. As to your other messages on this mailing list that haven't seen a lot of activity, I wouldn't take that too personally. Open up a ticket on trac, and let the traditional triaging take place to let you know if you're on the right track or not. Feedback on the ML is usually reserved for ideas or features that are contentious, though that's not always the case. It's obvious that you have an interest in improving Django, and that you have the skill and desire to make that happen. I really do hope you continue, despite the lack of activity on the ML at the moment. All the best :) Josh On Thursday, 5 March 2015 11:43:38 UTC+11, Thomas Stephenson 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. > > 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-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/87e331f5-8da0-49ed-8119-3c927108f1eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
