On Fri, Dec 3, 2010 at 10:56 PM, Russell Keith-Magee < russ...@keith-magee.com> 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 django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > I'm +1 on #4, as we discussed on IRC. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
