For some of my tests, I need the setUpBeforeClass method to run migrations on any modules present, and the tearDownAfterClass to migrate the modules back down again. Via the command line this is easy to do:
oil r migrate --modules
...to run the module migrations, and then:
oil r migrate --modules --version=0
...to reset them. However, in the tests I need to do this programatically, and I can't figure out how to execute the above commands using FuelPHP's Migrate class. Both the latest and version methods seem to require you to specify a module name, but I just want to migrate any modules that are present. Is this possible?
You need some hack to make this working.
Here is how oil does it:
https://github.com/fuel/core/blob/1.8/develop/tasks/migrate.php#L101
Alternatively you can use Module::loaded() to get the loaded modules.
You can then run migrations for each module.
Migrations are run by the Migrate class, so you can use that in your code if you want to run migrations:
$results = Migrate::up(null, 'mymodulename', 'module');
Similarly to the task you can also use down() and current().
Note that this will not load the module, so if one of your module migrations requires a class from the module, make sure to load the module first!
Related
I want to use symfony-cmf/simple-cms-bundle in symfony3.2 but It's support only symfony2. So I am looking to avoid check version at the time of development and will update on production.
Is it possible by pass validation through any configuration or command for temporary basis into composer or any other place.
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.
I need to be able to perform all of the available functions that the Package Manager Console performs for code first DB migrations. Does anyone know how I could accomplish these commands strictly through user defined code? I am trying to automate this whole migration process and my team has hit the dreaded issue of getting the migrations out of sync due to the number of developers on this project. I want to write a project that the developer can interact with that will create and if need be rescaffold their migrations for them automatically.
PM is invoking through PowerShell and PS cmdlets (like for active directory etc.)
http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference
The Package Manager Console is a PowerShell console within Visual
Studio
...there is essentially very little info about this - I've tried that before on couple occasions and it gets down to doing some 'dirty work' if you really need it (not really sure, it might not be that difficult - providing you have some PS experience)
Here are similar questions / answers - working out the PS comdlets is pretty involving - in this case it has some additional steps involved. And PS tends to get very version dependent - so you need to check this for the specific EF/CF you're using.
Run entityframework cmdlets from my code
Possible to add migration using EF DbMigrator
And you may want to look at the source code for EF that does Add-Migration
(correction: this is the link to official repository - thanks to #Brice for that)
http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs
http://entityframework.codeplex.com/SourceControl/BrowseLatest
(PM errors also suggest the origins of the code doing the Add-Migrations to be the 'System.Data.Entity.Migrations.Design.ToolingFacade')
If you need 'just' an Update - you could try using the DbMigrator.Update (this guy gave it a try http://joshmouch.wordpress.com/2012/04/22/entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commands/) - but I'm not sure how relevant is that to you, I doubt it.
The scaffolding is the real problem (Add-Migration) which to my knowledge isn't accessible from C# directly via EF/CF framework.
Note: - based on the code in (http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs) - and as the EF guru mentioned himself - that part of the code is calling into the System.Data.Entity.Migrations.Design library - which does most of the stuff. If it's possible to reference that one and actually repeat what AddMigrationCommand is doing - then there might not be a need for PowerShell at all. But I'm suspecting it's not that straight-forward, with possible 'internal' calls invisible to outside callers etc.
At least as of this post, you can directly access the System.Data.Entity.Migrations.Design.MigrationScaffolder class and directly call the Scaffold() methods on it, which will return you an object that contains the contents of the "regular" .cs file, the "Designer.cs" file and the .resx file.
What you do with those files is up to you!
Personally, I'm attempting to turn this into a tool that will be able to create EF6 migrations on a new ASPNET5/DNX project, which is not supported by the powershell commands.
I'd like to user c.transmogrifier outside plone. How far is it from being plone-independent?
Actually I see very few plone-related imports and plone-only-specific code inside the trunk so that it seems feasible.
Is there any roadmap or any todo/advice list for getting this?
I've created a runner for executing transmogrifier outside of plone via a commandline tool. At the moment that runner is part of funnelbweb. You can use the funnelweb script to run your own pipelines via "funnelweb --pipeline=mypipeline.cfg"
However we are in the process of migrating that code into a general module called mr.migrator. Mr.migrator will be both a commandline runner for transmogrifier pipelines and also a Plone UI to do the same.
collective.transmogrifier only depends on CMFCore, not Plone. I do have plans to make that dependency optional though, I simply haven't had the time to do so yet.