#4 seems reasonable to me, with #3 as a runner-up. As you said: the majority of users can ignore the new setting, which makes it far less of a burden while still offering flexibility.
All the best, - Gabriel On Dec 3, 7:56 pm, Russell Keith-Magee <[email protected]> wrote: > Hi all, > > I've been looking at #14799, and trying to work out the best approach > for a solution. I can see three options, none of which are are > particularly attractive. I'm looking for feedback on which one smells > the least. > > First off - the problem: > > * The test framework needs to create test databases > * The DB backend call to create the test database implies a call to > syncdb on that database > * But a post_syncdb handler can invoke a query on *any* database > * If the database required by the code in a post_syncdb handler > hasn't been created yet, the test system falls over during database > setup. > * The test databases are specified as a dictionary, so there's no > guarantee on the order in which tests databases are created. > > There is one obvious manifestation of this bug. If you run Django's > own test suite, and the 'other' alias is created before the 'default' > alias, the test suite fails to initialize, because the post_syncdb > handler for contenttypes tries to run ContentTypes.objects.get() on > the 'default' database, but that database doesn't exist yet. > > Jacob has committed an interim fix for this problem, which involves > simply ensuring that the 'default' database is created first. This > works for Django's own test suite, but doesn't work in the general > case -- if you have a router that directs contenttypes read queries to > 'other', the suite will fail for exactly the same reason. Similarly, > if you have some other post_syncdb handler with dependency on > something other than default, > > So - how can this be fixed? > > Option 1: The documentation approach: "You may only assume that the > default database exists when post_syncdb runs on a non-default > database". This is the non-solution; the current code on trunk will be > sufficient, but it will leave some users high and dry. > > Option 2: Force the use of SortedDict when defining DATABASES. This > removes the non-deterministic database creation order, but requires > imports in the settings file, and requires action on the part of every > person that has migrated to using the DATABASES format. > > Option 3: Split syncdb into two parts -- phase 1: create tables, and > phase 2: post_syncdb, custom SQL, index creation and initial data. > > I haven't implemented this -- but I've taken a look at what will be > needed, and it will be messy. The current syncdb command and > backend.create_test_db() API guarantees a full syncdb cycle, so > implementing this in a way that preserves backwards compatibility will > involve introducing a bunch of flags that only do partial syncdb runs > (either phase 1 or phase 2). There's also the question of whether this > will violate any existing expectations -- after all, we will be > effectively changing the order in which syncdb will be invoked in a > non-configurable way. > > Option 4: Introduce a per-database setting -- TEST_DEPENDENCIES -- > that allows the developer to explicitly encode the dependency between > databases. This means the developer can explicitly encode the > dependencies that exists in database creation order. We can default to > assuming 'everything depends on default' (which is what the current > trunk implements); but this gives end users the flexibility to define > any dependency they need. The patch on #14799 implements this solution > (although it needs some tests for the dependency resolution code and > documentation for the setting itself) > > My personal preference is for (4). I don't like the addition of a > setting, but it's a setting that most users will be able to ignore > (since there is a reasonably sensible default), and it is the most > explicit and configurable option available. > > Opinions? Alternatives? > > 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.
