On 28 touko, 17:46, Michael Manfre <[email protected]> wrote:
> > I don't know how to make this actually work so that Django's test
> > runner finds the correct test class from the backend's test module
> > instead of the generic backends test class. Optimally a backend could
> > subclass any test class to specialize or skip tests.
>
> django.tests.runtests.setup already has special handling for adding gis
> test apps. Something similar could be used to for database backends. Not
> 100% sure what would be a good way of flagging core tests as needing to be
> skipped or wrapped to expect failure, but we might be able to avoid that
> issue entirely with a combination of database feature flags and moving the
> vendor specific problem cases to the respective backends.
An example of what I think would be the ultimate solution:
class TestWeirdJoinConditions(TestCase):
def test_something(self):
...
If it turns out MySQL is having problems with this test, you could
then have a class somewhere in the backend:
from queries.tests import TestWeirdJoinConditions
class TestWeirdJoinConditionsMySQL(TestWeirdJoinConditions):
@skip
def test_something(self):
...
Assuming this could technically work (that is, there is a way to use
only the MySQL version of the class) it should be possible for a
backend to alter everything about the test class if need be, and the
test class doesn't need to know anything about the backend. So, no
dependency from queries tests to possible 3rd party backends. OTOH
this adds a dependency from backend to arbitrary test classes...
Just moving some tests to backends is a possibility. The problem is
that if some third party backend has problems with a test we will need
to move that test to backends without having anything in core
requiring that. This creates a weird dependency between Django and 3rd
party backends. Of course, we have that dependency already. For
example some tests use IntegerField(primary_key=True) instead of
AutoField, the reason is that SQL Server doesn't like manually setting
AutoField values.
> > For 3rd party backend support in general: My opinion is that we should
> > include them all in core. The rules would be:
>
> By "them", do you mean 3rd party backend tests or the entire 3rd party
> backend?
Whole backend. This could work if the idea is that core doesn't
guarantee that all backends are working all the time. The only
guarantee is that core tries to find a maintainers for backends. If
nobody is found, then the backend simply doesn't work.
This is the way device driver development is done in Linux. Basically,
if nobody cares enough to fix a broken driver, then it isn't a
problem. This turns out to work really, really well.
Interestingly something like this has already happened to Oracle GIS.
It was broken for a long time in 1.4 release (you couldn't save
anything IIRC). Then Jani Tiainen needed the GIS functionality, wrote
a patch and now GIS is in mostly working state. It still doesn't pass
the GIS tests, but that doesn't seem to be a problem in practice.
Based on how things work in Linux I think similar arrangement should
work in Django, too. The crucial point is that adding a new backend to
Django's code base must not add any significant amount of work to core
committers. If the idea is to add backends to Django's code base and
have any sort of core-committer guarantee that all backends work all
the time (that is, you need to run tests against all backends before
commit) then there is no way more backends in Django could work.
I don't know what others in core think about this...
Of course, the most important question is if maintaining backends in
3rd party projects is painful enough to justify this discussion. I
don't know. If there isn't a problem in practice, then lets not solve
imaginary problems...
- Anssi
--
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.
