Hi again,
On Wednesday 29 May 2013, Anssi Kääriäinen wrote:
>
> 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):
> ...
>
I think this can be done along the following lines: In the backend, include a
module for overriding tests (it could be a special module for overrides, or
just a regular test module) with:
from queries import tests as queries_tests
@override_parent(queries_tests)
class TestWeirdJoinConditions(queries_tests.TestWeirdJoinConditions):
@skip
def test_something(self):
...
With override_parent being something like
def override_parent(module):
def override(cls):
parent = cls.__bases__[0]
setattr(module, parent.__name__, cls)
return cls
return override
[perhaps the module argument can be removed, but the __module__ property on
classes is just the module name, and I'm not sure it's unique enough].
Then, we just need to make sure that the test runner imports these modules
before it collects test cases.
> 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 from backend tests to general tests. I don't see a problem there.
> 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.
>
The point this raises is, that sometimes modifying the test class is not
enough, and we'd need to modify the test app. I'm not sure if this can be done
along the same lines.
> > > 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 sounds like a very good plan if you think mostly on django-mssql or the
core Oracle backend. It sounds a little less attractive if you add the two
active forks of django-pyodbc, the fledgling Firebird backend, or the wholly-
IBM-owned DB2 backend -- of which, as far as I'm aware, none of the developers
are very active on this mailing list.
(For the record: I have been contributing significantly to the MSSQL backend of
South, and am interested in having an MSSQL backend in core).
> 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.
>
There is a difference in the development organization -- Linux development is
hierarchic, with "lieutenants" each responsible for their own area of the
kernel; which makes it much easier to make someone responsible for a set of
device drivers, but nothing more.
> 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.
>
(I am probably one of the obvious candidates to take care of this; alas, I am
not too well versed in GIS, and find other improvements in the Oracle backend
of higher priority. If anyone wants to work on it, I will collaborate as best
I can).
> 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 think this suggestion runs counter to what has been happening in contrib
lately -- several apps have been removed, mostly on the grounds that core
couldn't vouch for them. I have no strong opinion over which way is better,
but I think we should be consistent unless there are strong reasons not to be.
> 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...
>
I don't really know either, but I would guess the biggest pain point (and a
big difference between 3rd-party backends and 3rd-party apps) is the lack of a
well-defined API with stability guarantees (this has been mentioned on this
thread).
My 2 cents,
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.
