On Thu, Dec 9, 2010 at 6:37 PM, Shai Berger <[email protected]> wrote: > Sorry I haven't kept up with this discussion; althugh the issue has now been > closed, I'd like to say, > > On Sunday 05 December 2010 23:08:28 Nick Phillips wrote: >> On Sat, 2010-12-04 at 11:56 +0800, Russell Keith-Magee wrote: >> > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES -- >> >> Seems a lot more general than just test-related, anyway; I'd have >> thought it would make more sense to see (and name, and document) it as a >> general dependency of one database on the other - so >> creation/updates/migrations should all always happen in an order which >> takes any defined dependencies into account. I'm guessing that the test >> setup just happens to be the only place (within Django itself) where any >> of these processes are automated across multiple DBs at the moment? > > I fully agree. Why is it "test_dependencies" and not plain "dependends_on" ?
Mostly because we really didn't want to add this setting at all, but we've been backed into a corner. During the original multi-db design process, we considered allowing for the definition of dependencies, but abandoned the idea because of the complexity required to get automated synchronization correct in every case. For example, a master/slave setup only requires syncdb to be run on the master -- how do you declare this in DATABASES? What about multi-master configurations? Sharded configurations? Now, lets be clear -- I'm not saying that it is *impossible* to have such a declarative approach. I'm just saying that the original design process decided that it was going to be too hard to get consistently right on the first attempt, so we decided to leave that aspect out of the original implementation. Fast-forward to #14799, and we find that we can't avoid the issue -- we need to declare dependencies in order to avoid issues during testing. So I added a setting to fix the problem. You're certainly right in saying that the dependencies defined in TEST_DEPENDENCIES aren't strictly test specific. However, the reasons for avoiding the declarative approach still exist. I'm hesitant to introduce a 'runtime level' setting that is only ever used during testing, and I don't personally have the itch of solving the broader problem of syncdb depdendencies -- the manual approach hasn't caused me any particular difficulties. So, the options: * leave it as TEST_DEPENDENCIES, and explore the 'runtime' interpretations at some point in the future, possibly requiring the deprecation of TEST_DEPENDENCIES, * rename the setting to DEPENDENCIES, but only use it in testing context, with an option to do more with the setting in the future. Neither are particularly attractive options to me. I have a mild preference for the first, simply because of reasons of documentation confusion and YAGNI, but I could easily be convinced to swing the other way. 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 [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.
