Discussion :

[Pongten]

Bonjour à tous,

Connaissez-vous le moyen de spécifier explicitement une valeur pour une colonne de type identité ?

Je me trouve dans la situation suivante : je dois importer des données existantes dans une base et je passe par un modèle EF. Dans le cas de ma table des Pays, je dois conserver les IDs existant car ils sont utilisés via une clé étrangère de la table des adresses.

Cependant, dans la nouvelle table, la colonne ID est une colonne Identity.

Dans le programme d'import, j'ai beau préciser la valeur de la colonne Id, EF n'en tient pas compte et lui attribue la valeur automatique...

Existe-t-il un moyen qu'il prenne compte ma valeur, ou est-ce que je dois retirer l'attribut "Identity" le temps de l'import des données ?

Merci

Edit :

J'ai essayé de créer manuellement l'EntityKey, mais la valeur n'est quand même pas prise en compte au moment du SaveChanges.

[Pongten]

Bon, après de multiples recherches, j'en suis au point suivant :

Il n'est apparemment pas possible de modifier ce comportement.

Cependant, j'ai trouvé une solution pour contourner le problème.

La commande suivante positionne le compteur d'identity sur la valeur que l'on veut :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKIDENT('TableName', RESEED, valeur);

EDIT : Attention, après test, cette solution n'est pas idéale car le comportement de CheckIdent varie selon que la table a déjà contenu des données ou pas

Je vais donc abuser de cette commande pour importer mes données avec les bonnes clés..

Néanmoins, je suis toujours preneur si quelqu'un trouve "mieux"

[frecil]

Le plus propre, c'est de :
- désactiver temporairement "IDENTITY"
- importer les données
- corriger les clés primaires pour se conformer au mécanisme d'attribution automatique d'IDENTITY (en changeant la valeur des clés etrangères de concert).
- réactiver les contraintes

[Bluedeep]

Bonjour

Je me trouve dans la situation suivante : je dois importer des données existantes dans une base et je passe par un modèle EF.s.

J'aurais tendance à dire que déjà ça commence bizarrement : importer des données est typiquement une tâche pour l'ETL et j'ai un peu (beaucoup) de mal à imaginer la valeur ajoutée d'un ORM pour faire cela.

[Pongten]

Bonjour

J'aurais tendance à dire que déjà ça commence bizarrement : importer des données est typiquement une tâche pour l'ETL et j'ai un peu (beaucoup) de mal à imaginer la valeur ajoutée d'un ORM pour faire cela.

En fait dans ce cas, il s'agit d'une refonte d'une application existante (refonte est même est un faible mot) tout en souhaitant garder les données existantes.

La couche d'accès aux données existantes est fonctionnelle, et pour la nouvelle application, l'ORM entre en jeux.

Le choix d'utiliser l'ORM pour la migration des données existantes est uniquement lié à un gain de temps.

Sinon, il me semble évident que pour un projet de plus grande ampleur, c'est évidemment là solution à envisager.

Le plus propre, c'est de :
- désactiver temporairement "IDENTITY"
- importer les données
- corriger les clés primaires pour se conformer au mécanisme d'attribution automatique d'IDENTITY (en changeant la valeur des clés etrangères de concert).
- réactiver les contraintes

Le problème est que le modèle a été généré sur base d'une BD où les colonnes IDENTITY étaient spécifiées, les contraintes du modèles sont alors appliquées.

Pour utiliser cette solution, cela nécessiterait de parcourir les tables pour retirer la colonne IDENTITY, régénérer un modèle, effectuer la migration, parcourir les tables pour réactiver les colonnes IDENTITY, régénérer un modèle pour l'utilisation de l'application...

Car de ce que j'ai lu, il n'existe pas de commande T-SQL pour désactiver une colonne de type Identity. La façon de procéder revient à créer un colonne de même type, la remplir avec les valeurs de la colonne Identity, et dropper cette dernière.. Puis faire l'inverse pour réactiver l'Identity.

[frecil]

En fait dans ce cas, il s'agit d'une refonte d'une application existante (refonte est même est un faible mot) tout en souhaitant garder les données existantes.

La couche d'accès aux données existantes est fonctionnelle, et pour la nouvelle application, l'ORM entre en jeux.

Je pense que c'est effectivement une bonne idée pour un nouveau projet de partir sur un ORM comme EntityFramework plutôt qu'une couche d'accès aux données fait-maison. Ton code sera plus maintenable ainsi.

Le choix d'utiliser l'ORM pour la migration des données existantes est uniquement lié à un gain de temps.

Est-ce vraiment le cas ?
N'oublie pas que la migration est quelque chose de très particulier, que tu n'auras à faire qu'une seule fois à priori donc tu n'as pas besoin que le code de migration soit maintenable => l'ORM ne s'impose pas ici.

Sinon, il me semble évident que pour un projet de plus grande ampleur, c'est évidemment là solution à envisager.

Je n'ai jamais utilisé d'ETL, mais effectivement je doute que l'on en ait besoin , une simple solution à base de requête SQL ad-hoc voir un peu de code C# devrait suffire.

Pour utiliser cette solution, cela nécessiterait de parcourir les tables pour retirer la colonne IDENTITY, régénérer un modèle, effectuer la migration, parcourir les tables pour réactiver les colonnes IDENTITY, régénérer un modèle pour l'utilisation de l'application...

Tu vois tu te compliques vraiment la vie en voulant tout faire passer par l'ORM (régénérer un modèle temporaire juste pour la migration ).

. La façon de procéder revient à créer un colonne de même type, la remplir avec les valeurs de la colonne Identity, et dropper cette dernière.. Puis faire l'inverse pour réactiver l'Identity.

Oui, c'est bien celà comme solution tu garde l'ancienne clé primaire dans une colonne dédié, la nouvelle en auto-incrément, puis tu as un peu de travail pour mettre à jour toutes les clé étrangères pour pointer sur la nouvelle clé primaire, et puis hop "drop" de l'ancienne.

[Bluedeep]

Je n'ai jamais utilisé d'ETL, mais effectivement je doute que l'on en ait besoin , une simple solution à base de requête SQL ad-hoc voir un peu de code C# devrait suffire.

L'ETL ça sert justement à gagner du temps et à eviter l'écriture de scripts de migration susceptibles d'être complexes.

[Pongten]

L'ETL ça sert justement à gagner du temps et à eviter l'écriture de scripts de migration susceptibles d'être complexes.

Oui, mais nécessite de trouver une solution ETL, puis de s'y former, avant de pouvoir commencer à mettre en place la solution et là, même si c'est intéressant je suis vraiment trop court en temps


Pour ce qui est du reste, j'ai effectivement abandonné l'utilisation de l'ORM dans ce cas (malgré le workaround qui ne s'avère pas fiable en fait).

Je vais procéder comme frecil le suggère à un moment, à savoir que je vais moi même coder une programme console pour procéder à l'import des données.