Hi Maxi,
On Thu, Sep 13, 2012 at 8:20 PM, maxi <maxiroba...@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
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
