The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

[boito...@gmail.com]

Hi,

  While implementing  our collection management system based on Django, we are always excited by the extensibility of the framework.

  Most recently, we were exposed to the forms.MultiValueField and widgets.MultiWidget, that seem to offer composition capacities to users of the form and widget layers. Yet, we did not find any equivalent in the model layer, which seemed a bit surprising knowing that those 3 layers can work hand-in-hand very easily

  Is there a rationale to prevent implementation of such a models.MultiField class ? It could be a wrapper around the composite pattern in the model layer, allowing users to easily define custom models.Field that would leverage existing models.Field classes, by assembling them for specific purposes (while maximizing reuse).

----

This question was also raised in Stack Overflow here: http://stackoverflow.com/q/32014748/1027706. Below is a summary of the question's example motivating such feature request:

Imagine we want to store partial date in the DB (i.e., a date that is either complete , or just month+year, or just year). We could model it in the models layer using a models.DateField + a models.CharField (this last field storing whether the date is complete, or month+year, or just year).

Now, if we move to the forms layer, let's say we want a custom validation step that when a date is partial, the "unused" part of the DateField must be the value '1'. Because a ModelForm automatically maps one forms.Field to each models.Field, this constraint would require a cross-field validation.

On the other hand, if there was a models.MultiField, one could define a PartialDate class to inherit from said MultiField. It would then be seen by other layers as a single models.Field (implemented by aggregating two other models.Field, but that would be an implementation detail hidden from other layers). In ModelForm, this single models.Field would map a to a single custom forms.Field (probably deriving from forms.MultiValueField), and the validation step above would not need to be a cross-field validation anymore (more precisely, this validation could now happen at the forms.MultiValueField level, instead of the Form level). With this approach, it seems that the models.PartialDate and the forms.PartialDate could be written once, and reused in as many models and applications as possible, thus respecting Django's DRY philosophy.

----

Could a prototype implementation of such composite model field be of interest ?

[Tim Graham]

I think the general idea is captured in ticket #5929 -- Allow Fields to use multiple db columns (complex datatypes). Is that the gist of your proposal?

https://code.djangoproject.com/ticket/5929

[boito...@gmail.com]

Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :

I think the general idea is captured in ticket #5929 -- Allow Fields to use multiple db columns (complex datatypes). Is that the gist of your proposal?

Thank you for this link! It seems to discuss the same end result as what I tried to present in my first message: the ability to have a single models.Field managing an arbitrary number of DB columns under the hood.

The proposed approach is perhaps a bit different: if I understood the ticked correctly, it proposes to change the base Field class to make it possible, when deriving from it, to manage one or several DB columns. My first idea was more to mimic the composite pattern implementation already in use with forms.MultiValueField:

* The models.Field leaf classes would still manage a single DB column.

* Introduce a models.MultiField class, which is a container of models.Field classes (be it leaf classes or other MultiField classes). This container would address the multiple columns indirectly, through the interface of the composing fields. And, to the eyes of the rest of the code, it would behave as a normal field, notably offering the to_python() feature, hiding the composition in its implementation details.

I did not take time yet to try and assemble a prototype of this idea; In fact, I first wanted to confirm if such approach has not already been rejected in the past, before investing work in it ;) 

Does it sound like a feasible/interesting idea ? Or is there a good reason not to do it / too many obvious technical complications that I did not foresee ?

Thank you for reading,

  Ad

[Podrigal, Aron]

Have a look at [1] it is a composite field implementation.

[1] https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ
[2] https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
[3] https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst

--
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.
To post to this group, send email to django-d...@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/ca502bdb-da07-4ccc-a60e-5eb537cd80ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anssi Kääriäinen]

I've been thinking how we could move forward with composite fields without requiring too much changes in one go (large changes tend to never happen).

It seems the first step forward would be to introduce a composite field with the following properties:

class Foo(models.Model):
    x = models.IntegerField()
    y = models.IntegerField()
    point = models.CompositeField((x, y))

foo.point would always return a named tuplet. You could customize the return value to a full fledged object by implementing a custom subclass of CompositeField, but Django will not have any opinion on what should happen when you do:
    foo.x = 1
    foo.y = 2
    foo.point.x = 2
    foo.point.x == foo.x ???

this was one of the main concerns in the DEP.

In addition, on query side you should be able to use .filter(point__x__lte=...), and you should be able to select .values('point'). We also need migrations support, and likely changes in a lot of other places in Django.

The draft DEPs for this feature shouldn't be used as definite resource when implementing this feature.

 - Anssi

[schinckel]

As it turns out, this is the approach I've settled on for my Postgres Composite Type/Field implementation.

https://bitbucket.org/schinckel/django-postgres/src/6a6078d8a2cc30bfb61d093354b8228f76484a0c/postgres/fields/composite_field.py?at=default

Some issues I have identified are:

* it's not really possible at this stage to have something that triggers a migration operation to create the type. In practice I've just been writing that migration as a RunSQL operation, but it would be nice to have this included in the project state in some way. 

* There is a fair bit of duplicated code between the composite field metaclass and the django model metaclass. It's possible there are better ways to handle this.

I haven't done anything with querying/lookups at this stage, but that's an exciting possible feature.

I also blogged about this last year:

http://schinckel.net/2014/09/24/using-postgres-composite-types-in-django/

Matt.