2011-02-03 2 views
0

J'utilise actuellement le gestionnaire d'admin symfony pour manipuler une base de données. La base de données est déjà créée et utilisée et l'une des choses qu'elle fait différemment de ce que fait normalement une base de données symfony est d'utiliser un varchar comme clé primaire plutôt que la méthode de symfony d'utiliser ints pour toutes les clés primaires.Mettre à jour l'ID d'un modèle dans symfony

Le problème que je rencontre est de pouvoir éditer et mettre à jour cette clé primaire dans un formulaire. Le problème est que, lorsque j'essaie de modifier la clé, le formulaire renvoie une erreur et dit "Invalide". L'erreur, je peux supposer, vient du fait que le nouveau PK ne correspond pas à l'ancien. Je suppose que j'ai ces options:

  1. Supprimer l'ancien modèle, en créer un nouveau et l'enregistrer.

  2. Ne les autorisez pas à modifier l'ID. Ils devront à la place supprimer le modèle et le recréer. Ne leur permettez pas de créer ou de modifier l'ID et de le déduire à partir d'un attribut.

  3. Modifiez l'architecture de la base de données afin que le modèle dispose d'un entier PK auto-incrémenté. Ensuite, utilisez un index varchar unique pour le PK précédent.

Maintenant que je pense à ce sujet, le numéro 3 serait idéal parce que le modèle comme un champ « Nom », ce qui pourrait facilement avoir un ID déduit de celui-ci. Cependant, cela causerait toujours le problème dans 1 quand ils mettent à jour le nom.

Je n'aime pas du tout l'option 2, et je pense que je préférerais le numéro 4. Je suppose que 4 est le plus simple et que cela pourrait être fait, mais je voudrais au moins savoir si le numéro 1 pour référence future.

+0

Pourquoi avez-vous des PK modifiables? Quelles informations (modifiables par l'utilisateur) stockent-elles? – Jan

+0

Ce modèle dans ce cas est une catégorie. Le PK est une limace courte et descriptive. Par exemple, la catégorie peut être nommée «sports et loisirs», mais le PK serait quelque chose comme «sport». Il est utilisé pour éviter les doublons. – AndrewKS

+4

S'il s'agit d'une option, il peut être préférable d'utiliser une colonne de clé primaire entière et d'ajouter une contrainte unique sur les catégories s'il existe un risque de doublons. – Tom

Répondre

0

En fonction de votre commentaire, je refactoriserais la base de données. Je créerais un PK entier auto_increment et créerais un index unique sur la colonne slug.

Questions connexes