Yes, and the similar function for syncdb can be written too! On Sat, Dec 5, 2009 at 2:42 AM, Yuri Baburov <burc...@gmail.com> wrote: > Hi all, > > Database -> Model.Manager -> Queryset. > Save -> Model -> Database > > How about making a default Manager that's now "model.Manager" to be a > setting to override? > Like, calling current Manager a DefaultManager, and making "Manager = > load(settings.MODEL_MANAGER) or DefaultManager". Or > Manager.get_queryset calling customizable method. Any. > > And provide with django few most usable enhanced managers replacements. > This will solve both master/master, master/slave sharding and "this > table is at DB1, that is at DB2" use case (how to name it in a single > word?). > There should also be such general solution for complex model save > override. Maybe, Or Model.save calling such customizable method. > > Alex, you just don't get it seriously yet. Imagine the following: > In your project, you use the plugin application A written by other > people (and 25 other plugins B, C, D, ..., Z!). > It defines model A, and 3 views, each one use model A, with some > forms, templates, etc. > How are you going to change A.save and managers while keeping the views > working? > Monkeypatch it? Make patched version for each app? Well, then please > provide a method which will do this override for all models if called > from a single place in project, probably, settings. > > In large projects, single point of override on per-project basis is > required, not per-model. > > On Sat, Dec 5, 2009 at 2:12 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: >> On Fri, Dec 4, 2009 at 3:03 PM, Paul McLanahan <pmclana...@gmail.com> wrote: >>> On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >>>> We will not be adding a setting to pin an application/model to a >>>> specific database. We have already removed the Meta.using option. If >>>> you want to pin an application to a specific database it's fairly >>>> trivial to add a manager and override the save() method to use a >>>> specific DB. Our goal is to design a good long term API for having a >>>> flexible way to define exactly what DB any query goes to, and I >>>> personally have no interest in seeing short term stopgap APIs >>>> implemented. >>> >>> That's fine for apps under my control, but this leaves us without a >>> way of dealing with 3rd party apps outside of an unfortunate amount of >>> monkey patching. I certainly don't want the API to be "sort term" or >>> "stopgap", but I do want this ability. I don't see any other way to >>> accomplish a heterogeneous admin or partitioning of 3rd party apps. I >>> know and agree with the reasons that the Meta.using option was >>> removed, but it wouldn't have solved these issues either. Adding a key >>> to the DB configs may not be the right way, but I'm sure there is a >>> good way to accomplish this. >> >> Agreed. I was just writing basically the same reply. And in our >> defense, support for this functionality is the first thing one sees in >> the "Requirements" section on the Multi DB support wiki page: >> >> http://code.djangoproject.com/wiki/MultipleDatabaseSupport#Requirements >> >> I see nothing "short term" or "stopgap" about this; rather, it solves >> a specific and potentially common use case for multidb support in an >> elegant, extensible way that also fixes other issues with the current >> implementation (namely, the admin). >> >> That said, figuring out the right way to implement it is still up in >> the air. I proposed a separate setting; Paul proposed one integrated >> with the DATABASES setting. There are likely better ways to do it and >> I'm not attached to any particular one, but the functionality is key. >> >> Cheers, >> Tobias >> -- >> Tobias McNulty >> Caktus Consulting Group, LLC >> P.O. Box 1454 >> Carrboro, NC 27510 >> (919) 951-0052 >> http://www.caktusgroup.com >> >> -- >> >> 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. >> >> >> > > > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com >
-- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
