Hi,

I just opened a ticket in trac: https://code.djangoproject.com/ticket/21454.

Thanks Russell for you comments.

Regards,
Apostolis

On Wed, Nov 13, 2013 at 3:08 AM, Russell Keith-Magee
<[email protected]> wrote:
>
> On Tue, Nov 12, 2013 at 4:20 PM, Apostolos Bessas <[email protected]> wrote:
>>
>> Hello,
>>
>> I would like to ask, whether the following feature should/could be
>> part of Django.
>>
>> There are cases that you would the database to handle certain fields.
>> For instance,
>>
>> - set fields to their default value in the dabase-level (such as a
>> `created` timestamp),
>> - have the value of fields computed always by the database (e.g. with
>> a trigger),
>> - have virtual fields in the database etc.
>>
>> The first case is especially important for timestamps, since setting
>> the default to `NOW()` will make sure (at least in postgres) that all
>> rows inserted under the same transaction will have the same timestamp
>> (compared to how auto_now_add works). This means that, when you insert
>> a lot of objects in one transaction, they will all have the exact same
>> timestamp. Moreover, relying on the database for setting default
>> values to fields reduces the amount of data that need to be sent to
>> the database server.
>>
>> The second and third case allow to move some of the logic to the
>> database and take advantage of some features they offer as well as
>> speed up some things.
>>
>> I understand there are alternatives at python-level, but I am not sure
>> how well they would work for high-traffic sites etc, without resorting
>> to raw queries for certain operations.
>>
>> In order to achieve this (without resorting to hacks, like ignoring
>> the values that django sends in the database), django should ignore
>> these fields, when constructing an INSERT or UPDATE query. This could
>> be done by allowing a field to tell django to ignore it on INSERT or
>> UPDATE queries, the same way it does now for AutoFields.
>>
>> You can find an implementation of this approach at
>>
>> https://github.com/mpessas/django/commit/a663d8f95d9cca5112ccd33e3a303cae82908b60
>> and a demo project at https://github.com/mpessas/dbfield (timestamp
>> app).
>>
>> So, does this sound like something that should be in core django? If
>> so, should I create a ticket in trac? Can anyone think of a better way
>> to achieve the same effect?
>
>
> Broadly speaking, it sounds interesting, and is at least worth a ticket in
> Trac. I don't have a whole lot of use for this myself, but I can see how
> others might.
>
> Regarding the specific implementation you've provided -- I don't see why
> use_on_update/insert need to be class variables, instead of instance
> variables like all the other field configuration flags. This would have the
> benefit that you don't need to subclass every field that you want to be
> INSERT-ignored; you just need to pass in CharField(max_length=100,
> use_on_insert=False).
>
> As for other ways to the same effect -- the only alternative I can think of
> would be to treat this as a model-level property, effectively a default
> value for save(update_fields). This would be the approach to use as a ghetto
> implementation without requiring any modifications to Django itself (you
> just need to provide a save() implementation that removes the fields you
> want, based on whether pk is set), but as a solution for core, I think a
> field configuration argument is the better approach.
>
> 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/CAJxq848QVnvU6ce%2B4zZZtLA2agsgDQRbr7e70HFyUN9gbWOJ3Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/CAEa3b%2BqK3z4HJ9X5t_PauVZcQw4wBj5xMni3srMm1xVCapDVLA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to