Rather than use a trigger (which is DB-specific and also hard to debug because not part of your code base), suggest you use signals[1].
Derek [1] https://docs.djangoproject.com/en/dev/topics/signals/ On Saturday, 8 December 2012 04:27:50 UTC+2, Chris Cogdon wrote: > > It's a simple performance vs storage question. > > Storing a calculatable field also risks it getting out of sync with > reality, but if you're doing the query on that _so_ much, then its usualyl > worth it. > > Also, with the right database and a trigger, that's something the database > can ensure for you. Ie, a field that the database updates for you. > > > On Friday, December 7, 2012 5:54:37 PM UTC-8, Victor Hooi wrote: >> >> Hi, >> >> I have a "ranking" field for an item that returns an integer between 1 to >> 10 based on a number of criteria of each item. >> >> My question is - what are the pros and cons of using a model method to >> return this, versus overriding the save() method and saving it directly >> into a normal IntegerField on that item? >> >> I understand that model methods *won't* let me use them within QuerySet >> filters on that item - is there any way around that? >> >> If I just override the model's save() method to get it recalculate and >> save that field each time, I can use it within QuerySet filters. Any cons >> with that approach? >> >> What do you guys tend to use in your projects? >> >> Cheers, >> Victor >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/G7fp5OLkapgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
