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.
