10
votes

Changer le schéma de la base de données de cadre d'entité au moment de l'exécution

Dans la plupart des applications ASP.NET, vous pouvez modifier le magasin de base de données en modifiant les connexions au moment de l'exécution. IE Je peux passer de l'utilisation d'une base de données de test à une base de données de production en modifiant simplement la valeur du champ "Database" dans la section ConnectionsRing

J'essaie de changer le schéma (mais pas nécessairement la base de données elle-même) avec le cadre d'entité mais pas de chance.

Le problème que je vois est que le contenu SSDL dans le fichier EDMX XML stocke le SCHEMA pour chaque entité.

Voir au-dessous xxx

, j'ai modifié la valeur d'attribut de schéma sur "prod" du test et ça fonctionne.

Mais cela ne semble pas être un bonne solution.

  1. Je dois mettre à jour Evert Entity Set ainsi que les procédures stockées (j'ai +50 tables)
  2. Je ne peux faire que cela un moment de compilation?
  3. Si j'essaie ensuite de mettre à jour ultérieurement, les entités modèles d'entité existantes sont déjà en cours de lecture en raison de l'EF qui ne reconnaissent pas que le tableau existe déjà dans l'EDM.

    toutes réflexions?


2 commentaires

Pour être clair, j'ai des produits et testez sur différents serveurs. La situation réelle est que je souhaite passer d'une machine à l'aide d'une instance de MySQL 2 versions de mon application. Chaque version doit exécuter sur un «schéma» distinct. EF stocke le nom de schéma dans le cadre du fichier SSDL EF et utilise ce schéma de conception pour générer des requêtes SQL qui échouera car le schéma n'est pas guraiteed d'être nommé la même chose liée - Stackoverflow.com / Questions / 1307083 / ...


J'ai fini par utiliser cette Stackoverflow.com/questions / 19458943 / ...


8 Réponses :


1
votes

La chaîne de connexion pour EF est dans le fichier de configuration. Il n'est pas nécessaire de changer le fichier SSDL.

Modifier

Avez-vous le schéma de produit et de test dans la même base de données?

Si oui, vous pouvez le réparer en utilisant une base de données séparée pour prod et test. En utilisant le même nom de schéma dans les deux bases de données.

Si non, vous pouvez le réparer en utilisant le même nom de schéma dans les deux bases de données.

Si vous aurez absolument différents noms de schéma, créez deux modèles EF, un pour test et un pour prod, puis sélectionnez lequel utiliser dans le code en fonction d'une valeur dans votre fichier de configuration.


8 commentaires

Cela ne fonctionne pas. C'était ce que j'ai "supposé" fonctionnerait .. Mais l'entité cadre n'est pas si facile.


Nous faisons exactement cela sur tous nos projets EF, cela fonctionne pour nous. Nous déplacons la DLL compilée de DVL pour tester le test d'acceptation pour la mise en scène à la production, ne modifiant que les fichiers de configuration. Êtes-vous certain que vous mettez à jour le fichier de configuration correct?


Oui, je suis à jour le fichier de configuration correct. J'ai créé une solution de démonstration avec une seule table et des connexions et j'ai le même problème. Juste pour clarifier; Changer le web.config fait que l'EF a frappé la base de données "correcte". C'est la sortie SQL qui a un problème car elle contient le "schéma" dans le cadre de la sortie SQL. Exemple "Select * de Schemaname.TablEname"


Merci pour l'entrée Shiraz .. C'est un tel sénario commun, je ne vois pas pourquoi c'est un problème. L'avantage technique que je constate, c'est qu'il permet à EF d'utiliser 2 bases de données / schéma pour modéliser des trucs. Mais cela craint vraiment. Les solutions que vous avez appelées à propos de disposer de multiples bases de données sonne soiable mais HM .. Installez une autre instance de MySQL pour exécuter une autre version de mon application. Cela ne va pas aller à l'échelle et ce n'est pas une vraie solution. Imaginez si toutes les applications .NET ont besoin de cela. Avoir 2 instances SQL Server pour chaque version de l'application. :(


Vous pouvez avoir de nombreuses bases de données dans la même instance de SQL Server. Mais je ne suis pas sûr de MySQL.


Vous devez donc vraiment changer le schéma, pas la DB que vous êtes connecté? Je déteste ça quand je reçois cette réponse, mais il semble juste: peut-être devriez-vous reconsidérer le design. Le schéma est vraiment une partie de l'identité de la table. Donc, ce que vous êtes en quelque sorte essayez de faire, c'est dire «Je veux changer les noms de toutes les tables que je pose au moment de l'exécution.» Bien que ce soit faisable, ce n'est pas très pratique. Je suis d'accord avec les autres commentateurs de mettre vos données de test dans une base de données différente.


Un autre commentaire sur la mise en place de vos données de test dans une base de données séparée: cela vous permet d'avoir une sauvegarde séparée pour votre test et vos données de production. Vous ne voulez probablement pas souffler vos données de production à chaque fois que vous souhaitez réinitialiser vos données de test. Je ne sais pas grand chose à propos de MySQL, mais SQL Server autorise plusieurs bases de données sur un serveur.


Changer en fait que le nom du schéma de la même table est assez utile dans le scénario où vous devez mettre à jour quelques grandes tables R / O en arrière-plan, mais ne peut éteindre que si vous ne les utilisiez que si vous ne les utilisez que tout.



2
votes

Le moyen le plus simple de résoudre le problème est de supprimer manuellement toutes les entrées telles que "Schema =" Schemaname "'de la partie SSDL du modèle.
Tout fonctionne correctement dans ce cas.


3 commentaires

Ok .. je l'ai fait. Le problème est après avoir mis à jour le modèle L'attribut Schema revient. Existe-t-il une solution «plus difficile» qui ne se cassera pas lorsque j'essaie de mettre à jour le modèle?


Il s'agit d'une limitation connue du modèle Microsoft Update à partir de l'assistant de base de données - il écrase toutes les modifications manuelles apportées au modèle de stockage (SSDL). Les utilisateurs de DotConnect for MySQL ont la possibilité d'utiliser l'outil de développeur d'entité (il permet l'édition de modèles EF de conception et n'a pas le problème mentionné). Désolé, mais MySQL Connector / Net n'est pas pris en charge par le développeur d'entité.


FYI - J'utilise dotconnect pour MySQL mais pas l'outil de développeur d'entité



1
votes

Lorsque je crée un nouveau "modèle de données d'entité ado.net", il existe deux propriétés "Nom du conteneur d'entité" et "Espace de noms" disponible pour l'édition dans la vue de conception. À l'aide du nom de noms.EntyContainerName, vous pouvez créer une nouvelle instance. Spécification d'une chaîne de connexion.

mententies e = nouvelles mentyties ("Connstr");
E.MyTable.count ();

Je ne suis pas sûr que cela vous aide ou non, bonne chance!

En outre, il s'agit d'un bon cas pour plusieurs couches (ne doit pas nécessairement être des projets, mais pourrait être).

solution
* Dataaccess - entités ici

* Service - Enveloppes d'accès à DataAccess
* Consumer - Service d'appels

Dans ce scénario, le service appelle le consommateur, qui passe dans le facteur détermine quelle chaîne de connexion est utilisée. Le service instancie ensuite une instance d'accès aux données passant dans la chaîne de connexion appropriée et exécute la requête du consommateur.


0 commentaires

2
votes

Mise à jour En lisant vos commentaires, il est clair que vous souhaitez modifier le schéma référencé pour chaque dB, pas la base de données. J'ai édité la question de clarifier cela et de restaurer l'échantillon EDMX que vous avez fourni, qui a été caché dans le formatage d'origine.

Je vais répéter mon commentaire ci-dessous ici:

Si les schémas sont dans le même dB, vous ne pouvez pas les changer de à l'exécution (sauf avec le code EF 4 uniquement). En effet, deux tables nommées et structurées identielles de deux schémas différents sont considérées toutes les tables entièrement différentes.

Je suis également d'accord avec JMARSCH ci-dessus: Je reconsidérerais la conception de la mise en place de données de test et de production (ou, en fait, rien de et de données de production ') dans le même dB. Semble être une invitation à la catastrophe.

Ancienne réponse ci-dessous.

Êtes-vous sûr que vous modifiez la chaîne de connexion correcte? La chaîne de connexion utilisée par l'EF est incorporée intérieure la chaîne de connexion qui spécifie l'emplacement de CSDL / SSDL / etc. Il est courant d'avoir une chaîne de connexion «normale» destinée à être utilisée par une autre partie de votre application (E.G., ASP.NET Adhéship). Dans ce cas, lors de la modification de DBS, vous devez mettre à jour de vos chaînes de connexion.

De même, si vous mettez à jour la chaîne de connexion à l'exécution, vous devez utiliser Outils pour cela , qui comprennent le format de chaîne de connexion EF et sont séparés du constructeur de chaînes de connexion habituelles. Voir l'exemple dans le lien. Voir aussi Cet aide sur l'attribution de chaînes de connexion EF .


6 commentaires

Oui, je frappe réellement la bonne base de données. Mais le problème est que le SQL étant généré à partir d'EF a le nom de la base de données "Durée de conception" a été préparé aux nappes. Dans les mots. Mon application exécute "Select * à partir de TestFoo.Users" contre la base de données PRODFOO ... mais TestFoo est le nom de base de données lorsque j'ai généré le modèle, il ne figure pas sur le serveur de production. Donc, l'erreur est "Impossible de trouver objet testfoo.utilisateur .."


TestFoo sonne comme un schéma nom, pas une base de données nom. Nom de dB ressemblerait à quelque chose comme dbname..schemaname.table.table. Est-ce que vos deux DBS ont des schémas


Je pense que tu as raison. Ce que j'essaie vraiment, OT faire est basculer entre différents schemas (schémas) dans une base de données. Un schéma est pour la production Un autre schéma est pour le test.


Ok, mais c'est une question totalement différente de celle que vous avez posée. Pourquoi les DBS de test et de production ne peuvent-ils pas être réellement différents) utilisent le même nom de schéma?


Si les schémas sont dans le même dB, vous ne peut pas basculer à l'exécution (sauf avec le code EF 4 uniquement). En effet, deux tables identiques nommées et structurées dans deux schémas différents sont considérées comme des tables entièrement différentes différentes.


Il suffit de prendre note du fait qu'il s'agit d'une exigence légitime pour une base de données Oracle où toutes les tables sont séchées ensemble dans une pile géante et le «schéma» double-devoir en tant que délimiteur DB.



2
votes

Désolé, ce n'est pas une réponse robuste, mais j'ai trouvé ce projet sur CodePlex (ainsi que cette question) tout en googling pour un problème similaire:

http://fmodeladapter.codeplex.com/

Les fonctionnalités comprennent:

  • Réglage du temps d'exécution du schéma modèle, y compris:
  • Réglage de la table de niveau de données préfixes ou suffixes
  • Réglage de la Propriétaire des objets de base de données

    Certains code de la DOCS: xxx

    }

    ressemble exactement à ce que vous recherchez. < / p>


1 commentaires

Bonjour Jfar, c'est intéressant .. Je ne sais pas si cela résout mon problème car je ne l'ai pas testé. Mais si cela fait ce que dit l'utilisation de son "usage". La différence dans quel "schéma" signifie dans MySQL vs MSSQL rend cette question difficile à tester. Je suis en train de migrer vers MSSQL de MySQL qui n'a pas ce problème.



0
votes

a résolu mon problème en passant à SQL Server et à l'écart de MySQL.

mySQL et MSSQL interpréter les "schémas" différemment. Les schémas dans MySQL sont les mêmes / synonymes de bases de données. Lorsque j'ai créé le modèle, le nom du schéma..qui est identique au nom de la base de données est codé dur dans le modèle XML généré. Dans MSSQL, le schéma est par défaut "DBO" qui devient codé dur mais ce n'est pas un problème car dans les schémas de MSSQL et les bases de données sont différents.


1 commentaires

Le vendeur de base de données de commutation n'est pas une réponse réelle à la question pour personne, pas même pour vous, et vous devriez ajouter ceci comme un commentaire, pas une réponse ...



6
votes

J'ai ce même problème et c'est vraiment plutôt ennuyeux, car c'est l'un de ces cas où Microsoft manquait vraiment le bateau. La moitié de la raison d'utiliser EF est la prise en charge des bases de données supplémentaires, mais sauf si vous allez d'abord le code qui ne résout pas vraiment le problème.

Dans MS SQL Changer le schéma a très peu de sens, car le schéma fait partie de l'identité des tables. Pour d'autres types de bases de données, le schéma ne fait presque pas partie de l'identité de la base de données et ne détermine que l'emplacement de la base de données. Connectez-vous à Oracle et à modifier la base de données et à changer le schéma est essentiellement synonyme.


1 commentaires

Je suis aussi ici à cause du scénario Oracle, et jusqu'à présent, j'ai résulté de la modification manuelle du fichier RAW .EDMX pour supprimer la partie de schéma des nœuds d'entréeset, ainsi que dans les relevés SQL générés ... Ça fonctionne, mais C'est une façon de devoir faire des choses.



1
votes

Voici une question similaire avec une meilleure réponse: Modification du nom du schéma sur l'exécution - Framework d'entité

La solution qui a fonctionné pour moi était celle écrite par Jan Matousek.


0 commentaires