Hi, Hmm, so are we saying that:
- Using model methods uses less storage, but performs worse. - Overriding the model's save() method uses more storage, but performs better. I understand the storage part - but I'm a bit confused about the performance part - how does one perform better than the other? Also - in terms of using them with QuerySets - there aren't any workarounds to use model methods with QuerySets are there? It seems like that would be a definite argument in favour of using the second method, right? Finally - thanks for the tip about signals() - so should I be using something like django.db.models.signals.post_save in addition to overriding save(), or instead of it? Cheers, Victor On Monday, 10 December 2012 10:49:22 UTC+11, Chris Cogdon wrote: > > Even though I'm a total database junkie (and where by that I mean > postgresql > mysql :) ), I have to agree with Mike. If you can keep it in > the model layer, do that. Once you start putting optimisations into the > database layer, you lose a lot of portability between databases: there is > no such thing as "standard SQL" for anything other than toy applications. > Optimisation tend to be very engine-specific. > > However, just remember that those optimisations are possible, and the > database is far more reliable for maintaining your invariants than the > client is. > > > > On Sunday, December 9, 2012 3:30:01 AM UTC-8, Mike Dewhirst wrote: >> >> >> >> For the sake of maintainability it might be better to keep all database >> manipulation in the model layer rather than split it betweem models and >> database. >> >> >> >> and, well, that code is part of the >> > code base too. >> >> Which means you need to keep pretty comprehensive documentation if you >> are doing database stuff in two areas. >> >> Personally, I'd keep it all in the django ORM until the project is >> mature and requires the final molecule of optimisation. >> >> Mike >> >> > >> > - Tom >> > >> >> >> >> 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...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> django-users...@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/django-users?hl=en. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Django users" group. >> > To post to this group, send email to django...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > django-users...@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/django-users?hl=en. >> >> >> -- 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/-/CBv6vkNLFe0J. 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.
