On Sunday, December 9, 2012 9:08:18 PM UTC-8, Mike Dewhirst wrote: > > On 10/12/2012 10:59am, Victor Hooi wrote: > > 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? > > I'm not sure what you mean exactly here but you can use them in model > methods. Use the class manager. > > ClassName.objects.filter(thing=self.this, whatever=self.that, etc=etc) > What I believe Victor is asking for is that the model method is on the left hand side of that equals.
On my understanding of the framework, my best answer is "no", because the query system is unable to construct a SQL query that will encompass your model method, since that's in python. This is a very classic "pre-calculate vs re-calculate" argument that a lot of applications go through. Django handles a bunch of these using "lazy" queries, that don't bother calculating things until it really needs them, but even so, needs some hints to get best performance (see things like select_related and prefetch_related). Here's some options for you: 1. Stick with a model method. Do most of your querying through django's ORM, but then do a post-filter in python using the results of the model method. This saves database space, and if the pre-filter result set is small, this will be pretty fast still. Howerver, if this is called a _lot_ you'll be hurt on performance. 2. Whenever you "save" a model, re-calculate the field and save it. This is very flexible, while chewing up a bit of space. This opens up the possibility of a desync between the source data and the calculated, but should be rare if you're never saving the model data outside of the save method (and your database handles transactions properly). Very fast if you're doing a lot of searching vs updating. But if you're updating FAR more often than running your search, you're wasting performance on the rarely used pre-calculation 3. If the calculation can be done at the database level, use the "extra" ORM method to do a search. This is better than 1, but will take a fair bit more database knowledge to get going, AND might tie you to a specific database implementation. 3a. Use a database "view" that presents the pre-calculation, making the ORM query a lot simpler. This means ensuring that you are allowed to update a view (postgresql 9.3 planned) or can somehow do a query on the view (which is a different table according to django). More django work here, and again might tie you to a particular database implementation So, my guess is... as long as you're doing a reasonable number of "queries" versus "updates" to the table, to make the pre-calculation worthwhile, just go ahead and set that pre-calculation in the model's save() method, -- 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/-/NkeuU2YvoaQJ. 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.
