running unit tests with legacy database: Error 1050, Table already exists

[dpalao...@gmail.com]

Hello,
I'm relatively new to Django, so it might well be a silly question...
I'm using Django-1.7 with Python-3.3.
I'm working with a legacy MySQL database. I tried both pymysql and mysql-connector-python, the errors are similar.

When I run the unit tests, for instance, with mysql-connector-python, I get

python manage.py test jobwatcher
...
mysql.connector.errors.ProgrammingError: 1050 (42S01): Table 'auth_group' already exists

During handling of the above exception, another exception occurred:
...
  File "/test/virtualenv/lib/python3.3/site-packages/mysql/connector/connection.py", line 638, in _handle_result
    raise errors.get_exception(packet)
django.db.utils.ProgrammingError: Table 'auth_group' already exists

I read that one has to use the inspectdb command to generate the models when working with legacy databases, so I did; and I also set the "managed" variale to False in the meta thing. For instance:

class JobMon(models.Model):
    id = models.BigIntegerField(primary_key=True)
    job_db_inx = models.IntegerField()
    value_avg = models.BigIntegerField()
    value_sum = models.BigIntegerField()
    mon_type = models.IntegerField()
    timestamp = models.IntegerField()
    is_valid = models.IntegerField()
    is_full = models.IntegerField()
    nodes_nr = models.IntegerField()

    class Meta:
        managed = False
        db_table = 'job_mon'

I tried different things, but I'm just shooting in the dark right now.

Can anyone give me a hint of whats going on and/or how to solve this problem?

TIA,

David

[Collin Anderson]

Hi David,

Interesting. Shouldn't the test database be a separate, fresh, empty database (not a legacy database)?

Thanks,

Collin

[David Palao]

Hi Collin,
Thanks a lot for the answer. I think you are right, and that was what
I was doing. Still, apparently the models could not be created
properly, or whatever.

However I think I managed to convert this problem to a different one
(not sure if I should start a new thread).
What I did was: remove the __pycache__ dirs, remake the migrations,
and remove some models that were created by inspectdb (django
related).

Now, the original problem has gone, BUT something (related, I think)
happens. With _meta.managed=False in my models I get
...
django.db.utils.ProgrammingError: Table 'test_job_mon.job_info' doesn't exist

The test I'm running is very simple:

class HomePageTest(TestCase):
def setUp(self):
from django.db.models.loading import get_models
self.unmanaged_models = [m for m in get_models() if not m._meta.managed]
for m in self.unmanaged_models:
m._meta.managed = True

def tearDown(self):
for m in self.unmanaged_models:
m._meta.managed = False

def test_there_are_no_job_items_in_empty_db(self):
njobs = JobInfo.objects.count()
self.assertEqual(njobs, 0)



The relevant model:

class JobInfo(models.Model):
job_db_inx = models.IntegerField(primary_key=True)
id_job = models.IntegerField()
id_user = models.IntegerField()
id_group = models.IntegerField()
account = models.TextField(blank=True)
cpus_req = models.IntegerField()
cpus_alloc = models.IntegerField()
nodelist = models.TextField()
nodes_alloc = models.IntegerField()
partition = models.TextField()
time_start = models.IntegerField()
time_end = models.IntegerField()
was_updated = models.IntegerField()
jobmondatacleared =
models.IntegerField(db_column='jobMonDataCleared') # Field name made
lowercase.
endupcount = models.IntegerField(db_column='endUpCount') # Field
name made lowercase.
approved = models.IntegerField()

class Meta:
managed = False

db_table = 'job_info'


Now, if I comment the line "managed = False" and run makemigrations,
the test passes.

But I have checked that "managed" is switched to True during the tests.

Any ideas?

Thanks in advance,

David

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b79d8ab2-38ef-489d-9563-c2474c58defb%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[dpalao...@gmail.com]

I think I should start a new thread. It is a different problem, after all.

> email to django-users+unsubscribe@googlegroups.com.