Controleer of het doeldatabaseschema voldoet aan wat in Entity Framework staat?

We hebben een proces waarbij ons script voor database-kernen out-of-band verandert in onze database van onze applicatie (en ze met Juneau versie) met onze codebasis. Ze zijn er goed in om er rekening mee te houden dat nieuwe kolommen nul zijn en geen bestaande gegevens wissen, maar af en toe een hernoeming van een kolom die niet volledig is gecommuniceerd. Dus zullen ze een aantal wijzigingen aanbrengen in het databaseschema op een testserver, we zullen Entity Framework bijwerken om met die wijzigingen te werken, en dan onze code vastleggen. Dit proces werkt goed, behalve voor wanneer het tijd is om te implementeren.

We hebben TFS ingesteld om de succesvolle build op de juiste servers te implementeren, maar er is geen garantie dat de database voor die omgeving is bijgewerkt. Het maakt ons niet uit als extra velden/tabellen/weergaven/etc. bestaan ​​in de doeldatabase, maar we willen de build wijzigen om te controleren of de database ten minste alles bevat waarvan EF op de hoogte is.

Ik keek naar deze vraag , maar ik heb niet nodig dat het schema exact overeenkomt. Bovendien willen we niet dat het de database rechtstreeks maakt/wijzigt. En deze vraag lijkt erop dat het proberen om een ​​soortgelijk ideaal te bereiken, maar nog steeds niet helemaal wat we willen bereiken. We willen alleen een integratietest van soorten om te verifiëren dat onze versie van EF werkt met het doelschema.

5

1 antwoord

Ik vraag me af waarom je je applicatie probeert te implementeren zonder wijzigingen aan de database. Uw applicatie is afhankelijk van de database, dus de implementatie moet altijd gebeuren na de database. Het lijkt erop dat u veel tijd zult investeren om validatie te ontwikkelen om uw onjuiste implementatieproces op te lossen (waarbij de vaststelling van het proces zelf de juiste oplossing is).

Hoe dan ook, u kunt enige "validatie" van de database maken, maar het zal enige tijd duren. Als u het EDMX-bestand gebruikt, kunt u het als xml openen en de bijbehorende SSDL deel dat alle verwachte tabellen, kolommen, relaties, weergaven (in de vorm van SELECT SQL-queries), opgeslagen procedures en functies beschrijft. U kunt dit XML-onderdeel parseren en systeemdatabaseweergaven ( sys.tables , sys.columns , ...) gebruiken om te zoeken of deze objecten in de database aanwezig zijn.

Een andere benadering kan zijn database diff gebruiken. hulpmiddel om uw huidige testdatabase te vergelijken met de doel-database. Dit vereist het gereedschap dat vanaf de commandoregel kan worden uitgevoerd en je zult de uitvoer moeten analyseren om brekende veranderingen te vinden.

1
toegevoegd
Ik ben het volledig eens over het implementatieproces, maar de database-guy vertrouwt de implementatiescripts die via Juneau zijn gegenereerd nog niet volledig om de scripting van de database-upgrades volledig te automatiseren. We moeten dus verifiëren dat niemand een handmatige wijziging heeft aangebracht in de getargete database of slechts een geüpgraded script gedeeltelijk heeft toegepast.
toegevoegd de auteur Agent_9191, de bron