On 31-7-2012 14:36, Joris wrote:
>
>> Hmm, I guess I'm missing the "real world use case" for this. Most
>> importantly, I'm missing how this slow model relates to the fast model
>> and what kind of query it is executing. I'm especially curious about the
>> "as this statement is executed as an instance of the model" bit.
>
> Ok, I'll try to explain this better. The fast model is coupled directly to
> a table. The Slow model is not, it is activated by a specific sql query
> that depends on a specific condition.
I thought about an alternative, since it seems your only reason to split
the models is performance and you prefer to have one model.
The prerequisite is that you know when you want to have access to the
slow data and make it available to the view.
The idea is borrowed from django.contrib.gis.db and it's GeoManager and
consists of implementing the raw sql as a method of the ModelManager and
adding the result of the query as attributes of the model.
For reference you can look at for example GeoQueryset.area()[1].
This will give you the ability to specify the queryset on a generic
class-based view to either be model.objects.all() for the fast version
or model.objects.calculate_slow_stuff() for the slow version.
[1]
https://docs.djangoproject.com/en/1.4/ref/contrib/gis/geoquerysets/#django.contrib.gis.db.models.GeoQuerySet.area
--
Melvyn Sopacua
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment