In terms of non-core backends (and I include Oracle in this) - my preferred option would not be to include them all in core Django, but to collate them in and manage them under the Django project - i.e. github.com/django/django-mssql. These are "looked after" by the Django project to ensure that there is one place to find that code base, but are externally maintained. This is effectively similar to the way that localflavor is progressing, although we should wait and see how that plays out first - there are some teething issues there at the moment.
In particular I'd be quite strongly against the main Django codebase shipping with potentially broken drivers - this will reflect very badly on the project for new users. On Wednesday, 29 May 2013 08:42:19 UTC+1, Anssi Kääriäinen wrote: > > On 28 touko, 17:46, Michael Manfre <mman...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
