On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > 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.
I'm afraid I don't see the connection between what you're describing, and the problem we actually have. The problem is determining whether model X is available on database Y. This is only required for metaprogramming purposes - so, for example, syncdb knows which models to synchronize onto a particular database, or an admin interface knows which models can be shown to the end user. As best as I can make out, you're addressing the problem that I've said we aren't addressing - that of presenting a useful end-user API for tasks like master/slave. If I'm mistaken, feel free to correct me - preferably with some sample code to demonstrate what you're talking about. Yours, Russ Magee %-) -- 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.
