Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[VB.NET] Entity Framework sans PK null
Bonjour,
J'ai un problème avec l'entité framework. Ma clé primaire doit absolument permettre des valeurs nulles, les entités se génèrent parfaitement par contre lors de la compilation j'ai une erreur comme quoi ma clé primaire ne doit pas permettre les valeurs nulles.
Comment faire pour passer par dessus cette erreur ?
Ma bd est une bd Oracle.
Merci
Il faudrait préciser ton besoin, car une clé primaire ne peut par définition pas être nulle.
Me semble qu'EF interdit les clé primaires nulles.
EF n'a pas grand chose à voir la dedans.Envoyé par Arnard
Les SGBD (en tous cas Sql Server) n'admettent pas en général (et heureusement !!!!) de PK nulle.
Cette demande est plus que bizarre : par définition cela n'a aucun sens de vouloir une PK nulle.
Il n'y pas d'erreur, ou plutôt si, mais du coté de ta conception.
Pour la corriger : faire une conception correcte et ne pas attendre de la part du DBMS qu'il se soumette à une conception de schéma baroque.
Une clef primaire est avant tout une notion technique (donc sa nullité n'a pas de sens), même si souvent elle est utilisée aussi comme notion métier (alors que les deux concepts devraient normalement être disjoints).
Effectivement si ta clé primaire peut être null il y a une erreur de conception.
Le mix de l'utilisation "technique-métier" des clés primaires est à mon avis une bonne chose (je trouve que ça permet de rendre la modélisation et certains bout de code plus parlant Exemple les findByPrimaryKeys généré dans les datasets), néanmoins ça peut apporter beaucoup de complications après coup qui peuvent être extrêmement couteuse si la conception a des lacunes.
En cas d'expérience insuffisante dans l'exercice de la conception, il est préférable d'utiliser systématiquement un champ numériques spécifique, non modifiable, avec incrémentation auto, qui ne sera jamais affiché sur l'écran de l'utilisateur pour les clé primaire.
Tout à fait !
Plus ou moins d'accord. (plutot moins que plusLe mix de l'utilisation "technique-métier" des clés primaires est à mon avis une bonne chose (je trouve que ça permet de rendre la modélisation et certains bout de code plus parlant Exemple les findByPrimaryKeys généré dans les datasets), néanmoins ça peut apporter beaucoup de complications après coup qui peuvent être extrêmement couteuse si la conception a des lacunes.)
Je ne suis pas d'accord (du tout) avec toi sur ce point : pour ma part, les champs à incrémentation auto doivent être réservés à une utilisation "métier" (N° de commande devant apparaitre sur le BC, ,N° de client sur facture, etc ...)En cas d'expérience insuffisante dans l'exercice de la conception, il est préférable d'utiliser systématiquement un champ numériques spécifique, non modifiable, avec incrémentation auto, qui ne sera jamais affiché sur l'écran de l'utilisateur pour les clé primaire.
En revanche, si le champ est là uniqiuement pour assurer l'unicité, il me semble bien préférable d'utilise un uniqueidentifier, qui sera la PK.
Cela a au moins deux avantages :
- Si l'application doit travailler un jour en mode déconnecté (cas type embarquée sur le portable d'un commercial), la fusion des données avec la base centrale s'effectue sans pleurs ni grincement de dents
- un objet peut être complet avec son identitifiant unique avant de passer par la case "persistence SGBD" (quand on y pense, ce n'est pas le taf du SGBD d'attribuer des caractéristiques à un objet).
C'est vrai qu'un bon vieux GUID est ce qu'il y a de plus efficace pour générer une clé primaire (et que la gestion des auto-incrément en déconnecté est une vrai saloperie).
Après l'autoincrémentation sur les données métiers c'est rarement un bon truc car le "métier" aime souvent introduire un mix de donnée significative + compteur (Ex année + département (ou vendeur) + compteur), enfin ça c'est les gout et les couleurs de la couche métier...
Mais je maintient quand même que si la conception est "blindée et rigide" il est plus propre d'avoir un couple de champs significatif pour la clé primaire plutôt qu'une champ "bidon" en tant que clé primaire et d'ajouter des contraintes d'unicité supplémentaire ailleurs.
Je suis conscient qu'il y a suffisament d'arguments valables des 2 cotés pour se prendre le chou pendant un bout temps...
Clé primaire vraiment nullable
Ok il manque surement quelques détails dans mon explication. Ma clé primaire est vraiment nullable car avec ArcGis, lors de la manipulation de donnée(versionnage) il faut que les clés soient nullable et c'est possible de le faire en Oracle. Ok ce n'est pas la meilleure facon mais dans la nouvelle version, ca devrait se corriger.
En prenant cela en compte, il m'est impossible de créer mon entity ?
NON NON NON NON
Aucun SGBD ne te permettera de faire une clef primaire nullable, ni Oracle, ni SQL Server, ni Sybase, ni MySQL. Si t'en vois un, jette le!
Voici la référence Oracle : http://download.oracle.com/docs/cd/A...nteg.htm#11342
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
CertesJe suis conscient qu'il y a suffisament d'arguments valables des 2 cotés pour se prendre le chou pendant un bout temps...
Ceci dit c'est un vrai sujet de discussion qui mérite débat et qui vaudrait presque le coup d'ouvrir un fil dans le forum "base de données" ou "géneral développement" (pour pas continuer à polluer le fil de tito55 qui semble tenir à ses PK nulles
D'un autre coté il y a la réponse au premier post du topic aussi
C'est pas faux.D'un autre coté il y a la réponse au premier post du topic aussi
Ah nan je proteste! Je veux la capture d'écran de la PK nulle! Y'a le DBA Oracle de l'année là où je travaille, faut que je lui montre ca
Retrouvez moi sur :
Pour le versionnage avec ArcGis, tous les tables ont une clés nullable avec Oracle.NON NON NON NON
Aucun SGBD ne te permettera de faire une clef primaire nullable, ni Oracle, ni SQL Server, ni Sybase, ni MySQL. Si t'en vois un, jette le!
Par contre dans mon cas, je pouvais modifier pour la mettre nulle et avec Toad j'ai eu une erreur comme quoi je ne pouvais pas changer non-nullable par non-nullable comme s'il ne voyait pas l'option nullable mais prenait pour acquis que la clé primaire était implicitement non-nullable, j'ai du désactiver la clé primaire, la mettre non-nullable et réactiver la clé.
En résumé, c'est possible de mettre une clé primaire nullable en Oracle par contre je ne jetterai pas Oracle
Oui mais jette ArcGisPour le versionnage avec ArcGis, tous les tables ont une clés nullable avec Oracle.
Par contre dans mon cas, je pouvais modifier pour la mettre nulle et avec Toad j'ai eu une erreur comme quoi je ne pouvais pas changer non-nullable par non-nullable comme s'il ne voyait pas l'option nullable mais prenait pour acquis que la clé primaire était implicitement non-nullable, j'ai du désactiver la clé primaire, la mettre non-nullable et réactiver la clé.
En résumé, c'est possible de mettre une clé primaire nullable en Oracle par contre je ne jetterai pas Oracle
Non mais plus sérieusement, peux tu nous faire une capture d'écran de la table sous toad? C'est pas pour être lourd mais je vois pas comment c'est possible... C'est définitivement impossible!
Et surtout fait un DESC de ta table (ca te permet d'avoir la description de celle ci). Il semblerait qu'il y'ait un bug sous TOAD (à ce que j'ai lu sur un forum)
Retrouvez moi sur :
Répondre avec citation
Partager