I'm learning Symfony2 and have just learnt about doctrine:migrations. It sounds like a great way of 'versioning' the database schema and deploying new schemas in production.
I've also been reading about data fixtures for development. Is there any way to version these in a similar fashion as the schema migrations, or should I just use GIT?
Migrations' versions have to be kept under version control. If GIT is your SCM, then it's fine.
Related
I am well on my way to utilizing EF7 CodeFirst with SQLite...but really want to employ DB Migrations at runtime. This is a desktop application (Click-once deployment) meant to sync with a main database when connection is available, and provide offline data when no connection is present.
I have pulled down the nuget pre-release versions and all is working, except I cannot find any documentation of how to apply the migrations at runtime. I can successfully Add-Migrations and manually Apply-Migrations...but need a way to programatically Apply-Migrations at runtime.
I've also browsed the EF7 open-source project, but could not get anywhere there.
Versions I'm using: Latest Pre-release as of 9/15/2015
EntityFramework.Sqlite v7.0.0-beta7
EntityFramework.Relational v7.0.0-beta7
EntityFramework.Commands v7.0.0-beta7
...et al...you get the picture.
I am asking for help to apply runtime migrations...or what is the documented/recommended path for programatically maintaining a local/embedded db using EF7 CodeFirst SQLite?
UPDATE:
I went back to EF6 with SQLite but then found out that there is not SQLMigrationGenerator for SQLite.
EDIT:
I believe ApplyMigrations() method referenced in one of the notes has been deprecated. Searching the repository, there is no reference to "ApplyMigrations".
Today you can invoke the extension method Migrate on the DatabaseFacade.
This method is only available when the using Microsoft.Data.Entity statement is present. It comes from the RelationalDatabaseFacadeExtensions class that is part of the EntityFramework.Relational package.
Still have to find out how to migrate up and down from the API.
I'm developing a web site with Symfony. I'm new on this framework. Before i used Laravel 5.0 and I need to have a database with rows.
I create my db with command prompt but now I don't find how to seed it.
There is a equivalent of Laravel seeders on Symfony?
No. Seeding was a feature added by Laravel. You’ll need to use a third-party package to load seeds/fixtures into your application: http://www.sitepoint.com/data-fixtures-symfony2/
All the answers here are a bit outdated and this question is the first result on google so for future readers:
Since Symfony 3 there is an official bundle for this very purpose
Installation: composer require --dev doctrine/doctrine-fixtures-bundle
Then write your fixtures in src/DataFixtures and run php bin/console doctrine:fixtures:load
Try this package https://packagist.org/packages/evotodi/seed-bundle. Looks like it's what you need.
Their readme
Symfony/Doctrine Seed Bundle
Used to load/unload seed data from the database. Example would be to load a table with a list of states and abbreviations, or populate the users table with initial admin user(s). Unlike the DoctrineFixturesBundle which is mainly for development this bundle is for seeding the database before the initial push to production.
I am working on a ASP.NET Web Forms project which is expected to experience lots of database changes even after deployment.
Our preference was to use Entity Framework 5, and the Database First design paradigm. However, since we have to make lots of changes to the database even after deployment, if I use database first approach, then every time I update my database, I will have to delete my entire model and regenerate it. Is there any best practices to make this process less painful?
You should use Code First, so that you can use Migrations.
More specifically I'd use manual Migrations.
With manual Migrations you can create Migrations at any point in time. A migration has the following information:
a snapshot of the current model
a set of "instructions" to upgrade from the previous migration
a set of "instructions" to downgrade to the previous migration
Apart from the necessary Migrations, you should add a new Migration when you deploy your app. For example, you can create a migration called "Version 1.0", when you deploy the version 1.0 of your app.
When you finish each new stable version, you simply add a new migration, for it, like "Version 1.1" or "Version 1.2".
The interesting part of migrations shows up when you have a deployed application version and you need to upgrade (or downgrade) to a new version.
There are commands that let you upgrade (or downgrade) a DB from one particular version
to another particular version. You can do it directly specifying a connection to the DB, or create a SQL script which will apply the changes to the DB. For example, if you deployed the version 1.0 in a customer server, and you need to upgrade the software to version 1.2, you can do this:
Update-Database -SourceMigration "Version 1.0" -TargetMigration "Version 1.2"
-Script
This will create a SQL script which can be run on the DB to upgrade from version 1.0 to 1.2.
If you need help about any of the Migrations commands, simply type:
get-help Update-Database -full
(Update-Database is a command name, you can specify any other like Add-Migration)
It's possible that you need to specify the project where the model is in, the connection string name, the name of the project with the .config file or some other things, depending on the specified parameters, and the structure of the projects in your solution.
To get more info on migrations, read MSDN EF Code First Migration.
NOTE ADDED IN EDITION: there is a new DB initializer that can automatically migrate to the latest version when the application runs. I've worked in a real application, and it works like a charm.
ALTERNATIVE SSDT
If you don't want to follow the advice, you can use SQL Server Data Tools (which can be installed inside VS, or work as an independente application, depending on the version you're using).
The idea of this tool is that you can compare projects (which are DB schema snapshots) to existing DBs, and generate the scripts to change the DB to match the schema in the project. (In fact you can compare any combination ofr project and DB)
If you keep versions of your project in a CVS you can even check the changes from one verison of the project to other version of the project.
NOTE ADDED IN EDITION: a SSDT project is a set of scripts that can build the whole DB, including all the objects in its schema. You can create it from an existing DB or viceversa. Then you can keep comparing any combination of DBs and SSDT projects, as soruce or target, and create an apply the scripts neccesary to change each particular object which has changes. (The scripts are created to change the target so that it looks like the source, but you can swap source and target easyly)
This is an alternative solution, but Migrations are much more powerful because you can customize them, for example to fill a "master table" when creating it, to set the initial value of a new column, and so on. If you use SSTD you'll have to do all of that by hand, and carefully keep track of it. So I highly recommend using Migrations.
Up until now I have been using the EF Power Tools beta to do this. I click on an empty project, select EF and then reverse engineer.
The PowerTools creates all the model tables and EF mapping tables for me. It's something I do quite often when our database changes and I need to see how the mapping classes have changed. It's not completely necessary but it saves a lot of work and makes life very easy.
From what I understand is this was added to EF6.1. However where ... ?
All I see from the demos is that now I have the ability to start from a database and generate code first. For this it seems I would have to create a new application and do a lot more. I miss the two click functionality of not being able to create the mapping tables.
Does anyone know if this is still available and if I just missed it. If not available then time to go back to EF Power Tools beta :-(
Install the EF 6.1 Tools from MS downloads, and add a new "ADO.NET Entity Data Model" to your project, and you will have the new option to generate "Code First from database" https://entityframework.codeplex.com/wikipage?title=Tooling%20Consolidation
Is there a standard way of cleaning your database before (or after) each test when you're testing with Symfony2/PHPUnit? There seems to be a standard, obvious way to do this in Rails but I haven't found an analog in the Symfony community.
You can either purge the tables with Doctrine's data purger or rebuild the schema before every test.
Purger is part of data-fixtures package: https://github.com/doctrine/data-fixtures
I once wrote a KernelAwareTest which rebuilds the schema before every test: https://gist.github.com/1319290
If you are using the LiipFunctionalTestBundle, database is purged on each loading of fixtures. If you don't need any fixtures loaded, you can still call $this->loadFixtures(array()); ("load no fixtures") to have database purged.