Code First Migrations - File Name - entity-framework-migrations

We are using EF code first migrations but having an issue with the filename that gets created. We notice that it is appending the date and time to the beginning of our migration name when scaffolding changes and creating a new migration. This causes our migrations to be out of order when having to add a patch migration (in release) and then merge that into our dev branch. IE the patch will be after the new migrations in the dev branch due to the date in the file name, but we need them to appear and be ran in a specific order.
Is there any way to turn off the date that gets appended to the beginning of the migration file name and have it just use the actual name of the migration?
I've tried renaming the file and the reference to the name in the designer but that doesn't work because it prompts me to re-scaffold the changes again.
Anyone have any suggestions?
Thanks!

one way to get rid of this naming is somehow to add your own naming automatically. I used to use the command prompt file (.cmd) to create a name automatically (including date and time). Doing so I just need to double-click the .cmd file and the migration with my own automatic file name will be performed.
here is my .cmd file content (for example add_migrations_Identity.cmd):
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c_%%a_%%b)
For /f "tokens=1-2 delims=/:" %%a in ("%TIME: =0%") do (set mytime=%%a%%b)
dotnet ef --startup-project MyProject migrations add Identity_V%mydate%_%mytime% -o Migrations/Identity -c IdentityContext
pause
and here my update .cmd file (as an example update_db_Identity.cmd):
dotnet ef --startup-project MyProject database update -c IdentityContext
pause

Related

Two output file names resolved to the same output path migration.init in mvc

I am working in MVC and running with this problem "Two output file names resolved to the same output path '..\migration.init.resources'"
At first i run this command "Enable-Migrations" successfully after making changes in code i run "Add-Migration init" in console an error occur " project failed to build" with "Two output file names resolved to the same output path '..\migration.init.resources'"
I have deleted all migration.resouces files from obj folder, unload, reload and also restart the project but all goes with same error
I faced the same issue and solved :
1. Delete the Migrations Folder
2. Delete the line of code which uses Migrations.Configuration Namespace in Global.asax.cs file
3. Use Code First Migration to generate the new Migrations file and Folder.

Different Application Name For Development/Release Build

I have an iOS application that has "sysadmin" only features when in the development build which are removed for the release build.
What is the easiest way to have two builds on our testing devices in house, one in development mode, and one in release mode that have different names on the iOS home screen?
The current situation is that when we want to test the release build, I have to manually rebuild it for each device. When we want to switch back, I have to once again manually rebuild the application.
As LoVo mentioned - you will need different app-identifiers and bundle display names. Here's how I would approach the problem:
In Project's build settings set the following values:
Preprocess Info.plist File - Yes
Info.plist Preprocessor Prefix File - InfoPlist_proc.h
Add the header generation script to your Xcode project.
The script in ruby should look like this:
#!/usr/bin/env ruby
# build type is going to be passed
build_type = ENV["CONFIGURATION"]
proc_header_path = File.join(ENV["SRCROOT"], "InfoPlist_proc.h")
File.open(proc_header_path, "w+") do |f|
f.write("#define BUNDLE_IDENTIFIER com.company.app.#{ build_type.downcase }\n")
f.write("#define BUNDLE_DISPLAY_NAME \"My App #{ build_type.downcase }\"")
end
Now in the "Build" stage of your scheme (Cmd+Shift+,) create "Run Script" pre-action:
Add execution permissions to previously created script ($ chmod a+x script.rb) and set it to run from your pre-build script run phase:
Finally in your current Info.plist file change the bundle identifier and display name values with preprocessor definitions:
Now each time you build your app, the InfoPlist_proc.h file will be regenerated. This has a drawback though: to change your app's bundle identifier or name you would have to edit the script, not the Info.plist
But it also gives an advantage: you can inject the bundle version and short version string from what your cvs gives you. I usually use git rev-list --count --all for bundle version and git describe --tags --first-parent for short version string.
Hope this helps.
Set different App-Identifiers and Bundle Display Names

How to delete an app from a Rails project?

Initially I made 2 apps (app_a and app_b) in a single project in Ruby. Now I want to delete one (say app_a). How should I do so? Is deleting the app folder sufficient?
You need to drop your related database and then delete the app directory
# from app directory
rake db:drop
cd .. && rm -rf app_a
Rails generator command creates a copy of the framework. The app directory id self contained. Deleting it is enough. If you are using sqlite as your database then you can skip first command.
Deleting the app folder will get rid of it. Be sure to clean up your routes file if needed as well as get rid of a database table if it was created.

Opening a db/migrate/* file more effectively? Wildcard to complete the beginning of the name of the file?

Working from a bash shell and utilizing vim, I generally have a pretty effective workflow. However, when I attempt to access files in the db/migrate directory of a rails project, it becomes very tedious to access the files as the each contain a long integer at the being of their file names. I've tried vim db/migrate/*name_of_migration.rb but to no avail.
Is there a way to access files via wildcard of in this manor?
If you're using vim-7.3, then you can do this from inside vim:
:set path=/path/to/your/project/root/**
:find migrate/*cr<tab>
and vim will show you the possible candidates for completion.
If you're typing the name of the migration correctly, I assure you that the * will match the leading digits.
For example, from the root of your project,
$ vim db/migrate/*create_users.rb
will open 20111123142812_create_users.rb.
Otherwise, my preferred method is to use
$ vim db/migrate
to "open" the directory in vim, and use the in-vim navigator to select the migration you're interested in from the list of files.

How to integrate a Liquibase migration into my grails build?

I have a Liquibase migration that I manually run to load seed data from several CSV files into my database. I would like to run this migration each time I run grails run-app.
I think I have two questions in one:
How to I integrate the migrate
command into my grails run-app ?
How do I clear the DATABASECHANGELOG
to allow me to run the same
migration over and over?
Or, is there a better way to load a lot of data into a DB from CSV files?
Question 1 - To integrate migrate command into run-app, you should listen for events thrown in run-app scripts. This is explained here, and a more complete article is here.
Question 2 - For clearing the database, perhaps you can write a migration that clears the db for you? The way I do it is use a little script I wrote that just drops and creates a db. It's for MySQL:
target(dropdb: "The description of the script goes here!") {
def x = 'mysql -u root --password=XXXX -e "drop database yourdb; create database yourdb default character set utf8; " '.execute();
x.waitFor()
println "Exit Value ${x.exitValue()}"
}
setDefaultTarget(dropdb)
Question #2: If you have particular changeSets you want to run every time, there is an "alwaysRun" attribute you can set on the changeSet tag.
For my money, it's easier to read the Liquibase Gant scripts and replicate what they do. They're simple and you'll have more insight into what's happening.
You should use the autobase plugin. It will run your migrations when the application starts.
It has a script to convert from an xml changelog to a groovy one as well so you don't have to manually convert it.

Resources