Testing django 1.5 with firebirdsql

[maxi]

Hi,

I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on Ubuntu 11.04 with Python 2.7
I'm working right now on a new django-firebird [1] backend which do use the new python firebird driver (fdb) [2].

Then, I'm running the django test suite and I get an error when it try to create serializers_regress_

generice928. Seem like django is trying to create a table without fields, like this:

'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );'

And this is not valid on Firebird.

What does it trying to test here?
Are there any way to avoid (or silence) this test ?
Where is defined this model?

Thanks in advance.
---
Maxi


[1] The old one use kinterbasdb
[2] http://pypi.python.org/pypi/fdb/

[Ramiro Morales]

Hi Maxi,

On Thu, Sep 13, 2012 at 8:20 PM, maxi <maxir...@gmail.com> wrote:
> Hi,
>
> I'm testing Django 1.5 (branch:master) from trunk against FirebirdSQL 2.5 on
> Ubuntu 11.04 with Python 2.7
> I'm working right now on a new django-firebird [1] backend which do use the
> new python firebird driver (fdb) [2].
>
> Then, I'm running the django test suite and I get an error when it try to
> create serializers_regress_
> generice928. Seem like django is trying to create a table without fields,
> like this:
>
> 'CREATE TABLE "SERIALIZERS_REGRESS_GENERICE928" ( );'
>
> And this is not valid on Firebird.
>
> What does it trying to test here?
> Are there any way to avoid (or silence) this test ?
> Where is defined this model?

Hopefully the following leads will be of some help:

As per the usual Dango policy for namign DB tables (i.e. prefixed by the app
name and then the model name) it is clear the test app is serializers_regress.

it its located in:
tests/regression_tests/serializers_regress

The Django test suite test apps are actually precisely that: Django apps. So
something you can do is to transplant them to a pristine project (copying the
app dir, adding it to INSTALLED_APPS, etc.).

Once you have that you can perform any of the actions manage.py allows you to
do with an app. With the advantage you have only that app and there is no
noise from the massive Django test suite:

For instance:

* Running ./manage.py sql serializers_regress
To see the DDL Django+your backend generates for the app models

* Running ./manage.py test serializers_regress
To run the tests, add -v2 to see the order in which the Django test
machinery creates the model tables in the test DB.

Now, looking at the 'GENERICE928' part of the table name, we have another
hint, ist corresponds to a model whose name begins (case insensitively) with
'generic'. A quick perusing of serializers_regress.models shows there are a
couple of them, and in particular there is this model::

class GenericIPAddressPKData(models.Model):
data = models.GenericIPAddressField(primary_key=True)

It has only one field, marked as the PK.

Wild guess: Your backend's creation.py isn't generating the DB field
corresponding to the (new in 1.4 IIRC) GenericIPAddressField field types
i.e. is generating no DDL for it. And there is the origin of your
no-fields-table DDL problem.

HTH

--
Ramiro Morales

[maxi]

Hi Ramiro,

Nice point.I was looking for some manner to just run database (orm)
related tests.

>
> For instance:
>
> * Running ./manage.py sql serializers_regress
>   To see the DDL Django+your backend generates for the app models
>
> * Running ./manage.py test serializers_regress
>   To run the tests, add -v2 to see the order in which the Django test
>   machinery creates the model tables in the test DB.
>
> Now, looking at the 'GENERICE928' part of the table name, we have another
> hint, ist corresponds to a model whose name begins (case insensitively) with
> 'generic'. A quick perusing of serializers_regress.models shows there are a
> couple of them, and in particular there is this model::
>
>     class GenericIPAddressPKData(models.Model):
>         data = models.GenericIPAddressField(primary_key=True)
>
> It has only one field, marked as the PK.
>
> Wild guess: Your backend's creation.py isn't generating the DB field
> corresponding to the (new in 1.4 IIRC) GenericIPAddressField field types
> i.e. is generating no DDL for it. And there is the origin of your
> no-fields-table DDL problem.
>

First, thank so much for your very clear response, It did help me a
lot.
The problem was, as you note, the missing definition of
GenericIPAddressField.

BTW, I've another issue related to one specific test.
In test/regressiontests/model_fields/models.py there is a model
defined as:

class BigD(models.Model):
d = models.DecimalField(max_digits=38, decimal_places=30)

Firebird doesn't accept that definitions for max_digits and
decimal_places (the max is 18)
It will be possible to add a DatabaseFeature attribute for avoid or
skip related tests?

Best Regards.
---
Maxi

[Anssi Kääriäinen]

On 15 syys, 01:05, maxi <maxiroba...@gmail.com> wrote:
> BTW, I've another issue related to one specific test.
> In test/regressiontests/model_fields/models.py there is a model
> defined as:
>
> class BigD(models.Model):
>     d = models.DecimalField(max_digits=38, decimal_places=30)
>
> Firebird doesn't accept that definitions for max_digits and
> decimal_places (the max is 18)
> It will be possible to add a DatabaseFeature attribute for avoid or
> skip related tests?

I have a feeling I have seen the max_digits issue before. Quick trac-
search didn't reveal anything, though. But yes, a database feature is
the way to go.

- Anssi

[charettes]

Here's the topic you were referring to Anssi.

https://groups.google.com/forum/#!topic/django-developers/AZrSn6LCLVU/discussion