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
On 31 touko, 15:51, Marc Tamlyn wrote:
> 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.
The thing is, this is *already* true. Oracle GIS was badly broken in
1.4 release
On 31 touko, 16:58, Michael Manfre wrote:
> On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn wrote:
> > 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 p
On Fri, May 31, 2013 at 8:51 AM, Marc Tamlyn wrote:
> 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. Th
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 tha
On 28 touko, 17:46, Michael Manfre 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
On Tue, May 28, 2013 at 2:26 AM, Anssi Kääriäinen
wrote:
> On 27 touko, 20:15, Shai Berger wrote:
> > On Monday 27 May 2013 19:37:55 Carl Meyer wrote:
> > I think a better solution for this is to keep the original method, and
> mark it
> > with skipUnless(is_core_db) -- we'd need to define is_cor
I have just run afoul of one of those "features that make no sense except
when combined with the test suite."In BaseDatabaseFeatures it looks
like this:
# Does the backend allow very long model names without error?
supports_long_model_names = True
What this flag actually does is (whe
On 27 touko, 20:15, Shai Berger wrote:
> Hi Carl,
>
> On Monday 27 May 2013 19:37:55 Carl Meyer wrote:
>
>
>
>
>
>
>
>
>
> > Hi Shai,
>
> > On 05/27/2013 09:26 AM, Shai Berger wrote:
> > > I'm working on fixing some failing tests under Oracle, and I ran into
>
> > > commands_sql.tests.SQLCom
Hi Carl,
On Monday 27 May 2013 19:37:55 Carl Meyer wrote:
> Hi Shai,
>
> On 05/27/2013 09:26 AM, Shai Berger wrote:
> > I'm working on fixing some failing tests under Oracle, and I ran into
> >
> > commands_sql.tests.SQLCommandsTestCase.test_sql_all()
> >
> > [...]
> >
> > For now, I will
Hi Shai,
On 05/27/2013 09:26 AM, Shai Berger wrote:
> 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 other
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
12 matches
Mail list logo
