Impossible de créer les tables de base Django dans ma BDD

Question

J'essaie tant bien que mal de créer les tables de Django (je parle des tables: authpermission, djangocontent_type...) dans ma base MySQL. D'après la doc et d'autres sources que j'ai pu lire, un simple python manage.py migrate suffit à le faire. Mais rien ne se passe dans base après avoir exécuté cette commande.

D'autant plus que ma console ne m'affiche aucune erreur ! Je vois pas bien ce que j'aurais pu oublier. J'ai vérifié la configuration de la base qui me semble correct:

'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'my_database',
    'USER': user,
    'PASSWORD': password,
    'HOST': '127.0.0.1',
    'PORT': '3306',
    'OPTIONS': {
       "init_command": "SET storage_engine=InnoDB",
    }
}

Comments

quelles sont les logs ?

quelles applications sont présentes dans INSTALLED_APPS ?

---

Alors les logs, les voici :

Operations to perform:
Synchronize unmigrated apps: license, authentification, staticfiles, datetimewidget, utils, messages, profiles, compressor, django_js_reverse, dbbackup, ldap_sync
Apply all migrations: core, sessions, supervision, contenttypes, django_cron, auth
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
No migrations to apply.

Et concernant la variable INSTALLED_APPS, elle est définit comme telle :

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'utils',
'datetimewidget',
'compressor',
'django_cron',
'core',
'django_js_reverse',
'dbbackup',
'ldap_sync'
)

---

La commande est tapée sans spécifier de nom de settings.py particulier ?

---

Non pas de nom de settings
EDIT: J'ai essayé en spécifiant le nom du fichier settings et ça ne fonctionne toujours pas.

---

Il faut aussi que tu poste ton arbo de projet complet, ainsi que ton fichier models.py.

---

tiens, me vient une idée completement conne, le nom de l'application 'core', je me demande si django n'arrive pas à créer ses propres à cause de cette appli en cherchant ses classes là dedans. En principe non mais bon ...

Answer 1

Mon problème est résolu. J'avais créé il y a quelques mois des routeurs pour chacune de mes apps car j'utilisais plusieurs bases de données. Ce n'est plus le cas actuellement et il devait y avoir un conflit à ce niveau là.
Merci pour votre aide ;)

Answer 2

Peut-être l'absence de migrations
python manage.py makemigrations
à réexécuter avec migrate à chaque modification des tables dans models.py

Answer 3

Il n'y a pas de migrations !
python manage.py makemigrations d'abord.
et à chaque fois que les models sont modifiés

Comments

J'ai en effet oublié de préciser que j'avais essayé de lancer cette commande, sans succès malheureusement.

Answer 4

T'as essayé ça ?

django-admin syncdb

Comments

J'obtiens le même résultat qu'avec python manage.py migrate

---

T'as essayé sans l'option SET storage_engine=InnoDB dans les settings ?

Est-ce que tu peux te connecter à mysql depuis le shell et créer une table manuellement avec le même username que tu utilise dans settings ?

Qu'est-ce que tu as dans les logs mysql ?

---

Ca change rien quand j'enlève l'option.
Et j'ai réussi à créer une table en passant par le shell sans problème.

---

Dans my.conf mets les deux logs:

log = /var/log/mysqld.log
log-error = /var/log/mysqld.error.log

et regarde ce qui se passe quand tu lance ta commande à la fois en shell et avec manage.py pour voir si mysql log bien la même chose lorsque tu créer des tables.

tu peux faire un:

tail -f  /var/log/mysqld.log

Pour voir en direct le fichier log, assez pratique.

Answer 5

après la creation d'une application toto de zero et creation de l'application 'core' que j'ai ajouté au settings.py je tape :

(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ ./manage.py migrate
Operations to perform:
  Apply all migrations: contenttypes, admin, auth, sessions
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying sessions.0001_initial... OK
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ vim toto/settings.py 
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ ls
core  db.sqlite3  manage.py  toto
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ django-admin startapp coreze

et on ne voit rien concernant l'appli "core", donc ajout de coreze à INSTALLED_APPS

copie d'un modele bidon

(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ cp core/models.py  coreze/
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ !./
./manage.py migrate
Operations to perform:
  Apply all migrations: admin, contenttypes, auth, sessions
Running migrations:
  No migrations to apply.
  Your models have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ ./manage.py makemigrations
Migrations for 'coreze':
  0001_initial.py:
    - Create model ServicesActivated
(foobar) foxmask@localhost:~/DjangoVirtualEnv/foobar/toto $ ./manage.py migrate
Operations to perform:
  Apply all migrations: contenttypes, auth, coreze, admin, sessions
Running migrations:
  Rendering model states... DONE
  Applying coreze.0001_initial... OK

Donc il semblerait que "core" soit pas adéquate comme nom d'appli

Comments

En es tu bien certain? Car on s'est pourtant inspiré de cette article : http://sametmax.com/organisation-dune-application-django/ pour faire notre arbo. Et jusque là, l'application "core" n'a jamais posé de soucis donc ça m'étonne un peu.

EDIT: J'ai testé en renommant l'app et ça ne change rien à mon problème :'(