Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

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

+1 vote

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",
    }
}
demandé 4-Mai-2016 par Alex85651 (130 points)
edité 9-Mai-2016 par Alex85651

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 ...

5 Réponses

+1 vote
 
Meilleure réponse

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 ;)

répondu 9-Mai-2016 par Alex85651 (130 points)
sélectionné 10-Mai-2016 par Alex85651
0 votes

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

répondu 4-Mai-2016 par Actif_Proph
0 votes

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

répondu 4-Mai-2016 par Actif_Proph

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

0 votes

T'as essayé ça ?

django-admin syncdb

répondu 4-Mai-2016 par max (892 points)

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.

0 votes

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

répondu 6-Mai-2016 par foxmask (2,880 points)

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 :'(

...