Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?

Sorry. We should probably set can_introspect_null = True on Oracle and restore the previous logic in the CharField introspection test. -- Aymeric. > Le 13 juin 2014 à 01:30, Michael Manfre a écrit : > > The feature was added by Aymeric for django-pymssql, which needs the

Re: 3rd-party database backends: Do you need a "can_introspect_null" feature flag?

The feature was added by Aymeric for django-pymssql, which needs the feature. Regards, Michael Manfre On Thu, Jun 12, 2014 at 6:17 PM, Shai Berger wrote: > Hi all, > > Bug #22816[1] is a test failure on Oracle. It was caused by the > introduction > of the

3rd-party database backends: Do you need a "can_introspect_null" feature flag?

Hi all, Bug #22816[1] is a test failure on Oracle. It was caused by the introduction of the "can_introspect_null" database-feature-flag, which was set to True for all core database backends except for Oracle; and use of that flag in the test of introspection of NullBooleanField. The easiest

Re: Loading fixtures once for each TestCase to improve running time

A long time ago (django 1.3 era) I wrote a library (no need to change django) to do exactly this, using savepoints to rollback: https://github.com/machinalis/django-fasttest It worked pretty well for a large project and provided a large speedup (i think it was about 5x) on a large test suite. But

Re: Loading fixtures once for each TestCase to improve running time

Data migrations are kind of separate to the per-test fixtures; one is "initial data" shared between testing and production, and one is test-specific code. #22487 was just to emulate database rollback on backends that don't have transactions, since we can no longer emulate it using "flush; loaddata

Re: Loading fixtures once for each TestCase to improve running time

Yeah as said that ticket resolved the issue that you can't test data migrations, so for now on you could use data migrations and test them. And I think one of the things we should definitly do is a guide for migrating fixtures to data migrations and work towards that path instead of fixing

Re: Loading fixtures once for each TestCase to improve running time

That ticket seems to address issues with initial_data and not necessarily deal with fixtures that are loaded for a specific TestCase. I do agree that we should encourage people to not use fixtures and build their test data within the scope of the test or the TestCase. Regards, Michael manfre On

Re: Loading fixtures once for each TestCase to improve running time

Just a quick question regarding to these posts / tickets. In the last few weeks we fixed: https://code.djangoproject.com/ticket/22487 So I think that we now don't need to rely on fixtures and should just tell the people to use that behavior in the first place. I mean I'm not a Django core

Re: Current check for explicit app_label will cause a lot of headaches

Hi Ben, This issue is tracked in https://code.djangoproject.com/ticket/21719. You'll see in that ticket why I failed to resolve it, and eventually gave up after wasting a few day on it. However, you can avoid it by following two simple good practices (that were already true before