On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > The idea of using a function that returns a single string but does > other processing is a novel approach, and one that I hadn't > considered. However, I'm not sure I'm especially fond of the idea of > requiring imports in a settings file, and the syntax you propose is > quite verbose. I'll have to think about this a bit. Thanks for the > suggestion, though.
Shouldn't all this be more abstract? For our non-relational branch we thought about something more flexible like a list of query proxies that sit between QuerySet/Model and sql.Query (QueryData in nonrel) and that can intercept query execution and instead run their own query code. For example, a proxy could emulate unsupported DB features like select_related for non-relational DBs. You could also use this for selecting the connection for each query (e.g., sharding by pk) and for spreading a single query across multiple DBs at the same time (e.g., if you want to find all users born in 1980 you'll have to run this query on all DBs of a sharded users table). The point is, QuerySet and Model shouldn't care about those details. They should only provide a high-level abstraction to the DB that is as expressive and simple as possible. The details can be implemented via add-ons, so everyone can map the DB abstraction to his real DB setup. Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
