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/-/Lq8wIUC1y1IJ. 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.
