Hi all,
I'm working on fixing some failing tests under Oracle, and I ran into
commands_sql.tests.SQLCommandsTestCase.test_sql_all()
which collects the sql_all command's output, and verifies it is as expected.
It includes, among others, these two lines:
# PostgreSQL creates two indexes
self.assertIn(len(output), [2, 3])
Which I read to mean: Actually, we expect 2 statements on all backends other
than PostgreSQL, and 3 on PostgreSQL.
The test fails under Oracle, because the Oracle backend generates four
statements.
Two ways to fix this are quite trivial: just add 4 to the list of "acceptable"
values, or specialize the test by database vendor -- require (len==4) on
Oracle, and (len in [2,3]) otherwise. The latter option is better in terms of
testing -- if something changes generation on Oracle, I'd rather that the
change not be accepted by the test on the grounds that MySql generates only 2
lines.
However, by this reasoning, it would also be better to special-case PostgreSQL
as well; so the test requires len==4 on Oracle, len==3 on PostgreSQL, and
len==2 anywhere else.
Except that this raises another issue: what about the 3rd-party backends? In
particular, Michael Manfre has mentioned here his attempt to make SQL Server
pass all the tests. If we special-case back-ends, how can we support the needs
of a backend that isn't in core?
For now, I will only special-case Oracle -- that should solve a standing,
release-blocker bug, and not change the semantics of the test otherwise; but
I'd like to achieve something better, more general and 3rd-party-backend-
friendly, for the future.
Your comments are welcome,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
