Impossible d'installer les tables de la base de données django-activity-stream

Question

En utilisant django-south, est-il possible de configurer une table uniquement sur la dernière configuration la plus récente sans appliquer toutes les migrations précédentes?

Nous sommes intéressés par l'utilisation d'un outil tiers (django-activity-stream) mais rencontrons des difficultés à exécuter toutes les migrations, pour des raisons assez inconnues (éventuellement des problèmes MySQL concernant un champ particulier) - en particulier la migration 003, qui génère une erreur

_mysql_exceptions.OperationalError: (1170, "La colonne 'object_id' de type BLOB/TEXT est utilisée dans une spécification de clé sans longueur de clé") " Je suis fortement persuadé qu'éviter les migrations et passer directement au schéma actuel évitera cela.

La capacité de migrer en arrière n'est pas nécessaire, seulement le besoin de nous amener au schéma actuel dès maintenant, et je ne veux pas bricoler le package pour gérer cela. Je n'arrive pas à établir les commandes, ou savoir si cela est même possible?

config:

south 0.7.6, django 1.3.x, mysql 5.5.x, django-activity-stream 0.4.4

Answer 1

Cette erreur survient en raison de la façon dont actstream gère ses clés étrangères génériques. Le problème survient avec MySql car il voit des champs de texte sans aucune longueur spécifiée.

Cette erreur peut être corrigée en faisant de la migration 0003 une opération nulle.

Modifiez les éléments suivants dans les migrations 0003_text_field_ids, 0004_char_field_ids dans actstream:

0003_text_field_ids.py:

1. supprimez tout dans def forwards(self, orm), def backwards(self, orm) et écrivez simplement pass dans les deux.
2. changez TextField en PositiveIntegerField.

0004_char_field_ids.py:

1. Dans def backwards(self, orm), changez TextField en PositiveIntegerField dans tous les db.altercolumns().

Cela rend la migration 0003 une opération nulle en utilisant pass pour les forwards et les backwards et fait que la définition du modèle utilise des PositiveIntegerFields pour les clés étrangères génériques, afin qu'elles restent dans le même état que la migration 0001 les a laissées. En faisant cela, la migration 0004 peut passer des PositiveIntegerFields aux varChars. Ensuite, la correction modifie la migration 0004 afin que la migration en arrière passe des PositiveIntegerFields au lieu des TextFields.

Cela devrait normalement corriger votre problème.

Answer 2

Je ne pense pas que le problème soit causé par les migrations, même syncdb vous donnera le même résultat.

L'erreur se produit parce que MySQL ne peut indexer que les premiers N caractères d'une colonne BLOB ou TEXT. Vous devez donc avoir un champ/colonne de type TEXT ou BLOB que vous essayez de définir comme clé primaire ou index.

Avec un BLOB ou un TEXT complet sans la valeur de longueur, MySQL ne pourra pas garantir l'unicité de la colonne car sa taille est variable et dynamique. Ainsi, lors de l'utilisation de types BLOB ou TEXT comme index, la valeur de N doit être fournie afin que MySQL puisse déterminer la longueur de la clé.

Essayez de résoudre ce problème, puis essayez d'appliquer la migration, cela devrait fonctionner correctement. et Oui, vous pouvez appliquer des migrations et sauter les anciennes, mais je vous recommande de ne pas le faire car ce n'est pas la façon dont south est censé être utilisé.

J'espère avoir rendu les choses un peu plus claires.