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
> https://code.djangoproject.com/ticket/5929
>
> On Monday, August 17, 2015 at 5:11:01 AM UTC-4, boito...@gmail.com wrote:
>>
>> 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 ?
>>
>>
>>
--
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
