On Jun 2, 7:57 am, Russell Keith-Magee <[email protected]> wrote: > Apologies for the long and rambling answer; I hope it's shed some > light on the source of my concern. To be clear -- I'm not completely > opposed to your idea of 'stickiness', and I can see how it might be > useful -- I've just got concerns about the predictability of the > resulting mechanism, and I'm not completely convinced that DB-routing > is the best analogy for comparable behavior.
Couldn't this specific use case be solved with use of threadlocals? Pass the "sticky" data around in threadlocals, have the get_query_set() return a correctly filtered qs based on the threadlocals data. While this isn't beautiful, it does solve the problem, and I don't see it any uglier than a router approach. I have also found that the DB-routing approach can lead to some problems with transaction handling: you don't actually know which database you will be using when you do: SomeModel.objects.all(). This means you will be opening a transaction to some database, and this again means that you need to close that transaction, at least when doing batch job processing. Django doesn't offer any good solutions to this problem currently. You need to use @commit_on_success for each database separately, but if you don't know which database you are using, then how do you do that? The autocommit option of PostgreSQL doesn't work, so you can't rely on that either. Still, there is no publicly documented API of how to close all used connections. I believe the above is one reason for idle-in-tx leaks. Just to show that while the DB-routing is an useful feature, it has the problem of action-at-distance, and that can lead to further problems. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
