Hi Russell, On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > 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.
Yes and no. Aren't both tasks (model location and sharding&master/slave API) highly connected? We don't know what the API for sharding, master/slave, etc. will look like, but I have the impression that we're already defining its settings format and planning changes that won't be necessary with Django 1.3, anymore. For example, as my suggestion shows, the admin interface does not have to (and must not!) know about the multi-db setup because that can be fully abstracted behind an sql.Query proxy API (actually, it must be abstracted that way because there can be lots of different ways to do sharding and you don't want high-level code to deal with those details). I am just concerned that you'll waste time on implementing something that will get removed in 1.3 shortly thereafter just because multi-db isn't ready for real-world use-cases, yet. I'd rather have a temporary very simple hack that binds a model to a single DB and that doesn't require any changes to the admin interface itself and code that uses the admin UI. This could indeed be specified in the settings as was already suggested. But it should be clear that this is just a temporary hack and 1.3 will provide a clean solution. 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.
