27-05-2014, 19:00
Pour vos problèmes avec south, mon collègue vous a déjà donné la solution dans son premier commentaire, à savoir mettre la ligne 'kwargs['on_delete'] = ...' en commentaire (plus simple qu'utiliser PROTECT qui nécessite plus de travail).
Explication: django gère les suppressions des objets référencés par ForeignKey suivant 4 méthodes : CASCADE, PROTECT, SET_NULL et SET. Les 3 premières sont triviales à comprendre, la dernière prend une fonction qui permet de coder le comportement à utiliser lors de la suppression. Malheureusement south ne gère pas ce dernier cas, et refuse de continuer, comme vous l'avez vu. Or south n'évolue plus en ce moment, car son auteur est en train de l"intégrer directement dans django, et south va devenir à terme la façon standard de gérer les tables (la commande syncdb va plus ou moins disparaître). À terme le problème de SET devrait disparaître (ainsi que des tas de bugs de south venant de sa non intégration), mais pour le moment on n'a pas le choix que de contourner les problèmes. D'où le hack qui consiste à commenter la ligne susnommée, qui fait que south voit cette FK comme étant en mode CASCADE, la valeur par défaut.
Pour le contribute_to_model():
Pour gérer l'ordre d'affichage des champs d'une Opportunity, vous avez 2 façons propres de faire:
Sinon pour l'idée de l'auto-incrémentation, c 'est une idée intéressante, nous le ferons si ça devient une demande récurrente (chez nos clients par exemple). Il y aurait sûrement bien d'autres amélioration à apporter aux CustomFields ; j'avais par exemple pensé à pouvoir les rendre obligatoires, ou mettre une valeur par défaut, quand je les ai fait il y a déjà quelques années, mais au final cela n'a pas eu l'air de manquer spécialement. Il faut bien voir que les champs supplémentaires s'accompagnent souvent de règles métier, et nécessitent donc du code de toute les façons (donc pas de problème pour ajouter ces champs avec contribute_to_model() ).
Explication: django gère les suppressions des objets référencés par ForeignKey suivant 4 méthodes : CASCADE, PROTECT, SET_NULL et SET. Les 3 premières sont triviales à comprendre, la dernière prend une fonction qui permet de coder le comportement à utiliser lors de la suppression. Malheureusement south ne gère pas ce dernier cas, et refuse de continuer, comme vous l'avez vu. Or south n'évolue plus en ce moment, car son auteur est en train de l"intégrer directement dans django, et south va devenir à terme la façon standard de gérer les tables (la commande syncdb va plus ou moins disparaître). À terme le problème de SET devrait disparaître (ainsi que des tas de bugs de south venant de sa non intégration), mais pour le moment on n'a pas le choix que de contourner les problèmes. D'où le hack qui consiste à commenter la ligne susnommée, qui fait que south voit cette FK comme étant en mode CASCADE, la valeur par défaut.
Pour le contribute_to_model():
- Pas de problème la fonction ne va pas disparaître ; django 1.5 permet de définir son propre modèle User, alors que pour le moment nous utilisons contribute_to_model() pour modifier le modèle User de django. Donc avec django 1.5, on pourra se passer d'utiliser contribute_to_model() sur User, mais cela ne veut pas dire que cette dernière va être supprimée. Nous nous en servons sans arrêt pour écrire le code spécifique de nos clients, donc pas de souci.
- Comme dit au dessus nous nous servons tout le temps de contribute_to_model(), donc nous serions au courant si elle ne fonctionnait pas avec south. En revanche vous vous y prenez mal : vous générez votre migration pour votre propre app (comme l'indique la dernière ligne), alors qu'il faut la générer pour 'opportunities'. En effet votre app n'a pas de modèle propre et se content de modifier ceux de 'opportunities', d'où la migration vide.
Pour gérer l'ordre d'affichage des champs d'une Opportunity, vous avez 2 façons propres de faire:
- En modifiant l'attribut 'template_name' de OpportunityBlock (dans creme/opportunities/blocks.py) pour mettre votre propre template (vous pouvez vous inspirez de creme/persons/templates/persons/templatetags/block_contact.html par exemple). Cela doit être faisable depuis le creme_core_register.py de votre app.
- En utilisant la fonctionnalité des blocs configurables décrite ici.
Sinon pour l'idée de l'auto-incrémentation, c 'est une idée intéressante, nous le ferons si ça devient une demande récurrente (chez nos clients par exemple). Il y aurait sûrement bien d'autres amélioration à apporter aux CustomFields ; j'avais par exemple pensé à pouvoir les rendre obligatoires, ou mettre une valeur par défaut, quand je les ai fait il y a déjà quelques années, mais au final cela n'a pas eu l'air de manquer spécialement. Il faut bien voir que les champs supplémentaires s'accompagnent souvent de règles métier, et nécessitent donc du code de toute les façons (donc pas de problème pour ajouter ces champs avec contribute_to_model() ).