On Tue, Mar 4, 2014 at 4:46 AM, Piper Merriam <[email protected]>wrote:

>
>
> On Saturday, March 1, 2014 4:29:43 PM UTC-7, Russell Keith-Magee wrote:
>>
>>
>> On Sun, Mar 2, 2014 at 1:07 AM, Aymeric Augustin <aymeric....@
>> polytechnique.org> wrote:
>>
>> On 1 mars 2014, at 09:14, Martin Matusiak <[email protected]> wrote:
>>>
>>> A structural reason is that you can't tell "assigning an attribute to an
>>> instance in order to save it to the database later" apart from
>>> "assigning an
>>> attribute to an instance being loaded from the database". So your
>>> proposal
>>> doesn't play nice with lazy loading of related instances, for example.
>>>
>>> Another reason is the impossibility of running validations involving
>>> multiple
>>> fields. If a validator depends on the value of two fields, one has to be
>>> set
>>> before the other, and you can't validate at that point.
>>>
>>
>> For me, this is the bigger reason why validation at time of assignment
>> isn't viable.
>>
>> In order to do multi-field validation at time of assignment, we'd need to
>> introduce some sort of transactional behaviour. Just thinking about this
>> makes my brain hurt.
>>
>>
> Russ
>
> This got me thinking about what the API for doing multi-field validation
> could look like.  I came up with two ideas that may or may not hold water.
>
> The simplest solution I could think of would be a setter method on the
> model that took **kwargs and set them on the model, calling validation
> after they've all been set.  Kind of a gross API, but it should work.
>

So, for the low low price of preventing you from using = for assignment,
you get data validation!

Not sure I see this as an improvement :-)


> The maybe cleaner idea would be a context manager that deferred validation
> till the end of the context block.
>
> with instance.validation_block():
>     x = 4
>     y = 5
>
>
Yes - like I said, transactional behaviour. And it makes my brain hurt
thinking about it :-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq84-KT6eY2bh0dpFVmhAfGpudYj1Jh27CAiDg0Q8avka51Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to