I know this feature has been already added in laravel 5.3, but I am using Laravel 5.1, how can I do it using 5.1 version? I've also searched it on internet, but there's only solution for 5.3. Hope you can help me, and for those who have the same problem.
You can just edit the batch of your migration, update it as last migration. For example, if the batch of the table is 73 and you already have 74 & 75 you can just UPDATE migrations SET batch = 76 WHERE batch = 73, now your table's batch is 76, RUN php artisan migrate:rollback , and there you go.
You can't rollback a specific table even in the latest version (5.4) of laravel. You can only rollback a particular migration. This question was asked recently and there a couple of answers which apply to 5.1 as well.
Rollback a specific migration in laravel5
If you are indeed talking about rolling back a specific migration then do this.
https://stackoverflow.com/a/30288058/5892849
https://stackoverflow.com/a/44100120/5892849
Related
Does anyone know when Rails 5.2 reaches end of life? Is there a central place where end of life dates for Rails are documented?
Rails don't do long term support of old versions. They only release security path.
You can get a better idea of how this work here:
https://guides.rubyonrails.org/maintenance_policy.html
It is important to emphasize that you have to keep updating the gem of rails to avoid incompatibilities in the future, see the case of the update of Github in rails 3 to version rails 6
https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/
https://github.blog/2019-09-09-running-github-on-rails-6-0/
Rails 5.2.Z is included in the list of supported series until June 1st 2022.
You can find the central place where end of life dates for Rails are documented at https://endoflife.date/rails
or at https://guides.rubyonrails.org/maintenance_policy.html
I believe Rails 6 is still "Edge" (unreleased) and Rails 5 is the latest released version. (See this Q&A for definitions.) As such, I believe there is no EOL date for Rails 5.
I believe you can find, essentially, EOL information by looking at the latest release notes, as discussed in this Q&A.
Until I think rails 5 (inclusive), one could add comments to the migration file, which then is dumped to the schema file. Will it be supported with rails 6 also ?
Thanks for any information.
in Rails 5 the support of adding comments in migrations was implemented https://github.com/rails/rails/pull/22911
the code is still present in the 6.0 stable branch
https://github.com/rails/rails/blob/6-0-stable/activerecord/lib/active_record/connection_adapters/abstract/schema_creation.rb#L88
We struggle a little and need some fresh ideas how to handle the migration-stuff.
We are acute developing new features and extensions for a huge website with a lot of new migrations (altering tables and ofc neu tables).
Every time if its getting close to merge into master or deploy the app we struggle a lot of the current scheme.
for example:
current version: 100
i create some migrations, 101, 102, 103, 104.
in another new branch i create 101, 102
my coworker is doing the same.
In total we are having 12 new migrations and its a mess to pull some other branches, running the migrations due its conflicting.
What is the best practice so handle this scenario?
Best practice is to update your Ruby on Rails version to something more recent than a few years old. Then you will have timestamped migrations. They were definitely present in Rails 3 (current version is 4), and I'm not completely sure, but I think they were even in some older versions of Rails 2.
Migrations are stored as files in the db/migrate directory, one for each migration class. The name of the file is of the form YYYYMMDDHHMMSS_create_products.rb, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The name of the migration class (CamelCased version) should match the latter part of the file name. For example 20080906120000_create_products.rb should define class CreateProducts and 20080906120001_add_details_to_products.rb should define AddDetailsToProducts. Rails uses this timestamp to determine which migration should be run and in what order, so if you're copying a migration from another application or generate a file yourself, be aware of its position in the order.
http://edgeguides.rubyonrails.org/active_record_migrations.html#creating-a-migration
UPD. As was clarified in comments, the problem is the need to merge schema.rb file, not the migration files. Just add db/schema.rb to .gitignore. If you don't use rake db:schema:load and friends, it's okay to do so.
I'm not a Rails developer (currently) so please forgive my ignorance on this.
One thing I've always liked about Rails is migrations and how it fills a need that's common across all languages and platforms. With that said, I am curious to understand what a certain scenario would result with the changes made in 2.1.
Rails 2.1 and higher, from what I can tell, made two changes to the migrations logic. The first was to use timestamp based script names when generated in order to reduce the probability of 2 developers working on the same file at the same time before adding the file to source control. So instead of 002_test.rb, it is now 20090729123456_test.rb when the script is generated.
The second item was that the Schema_Info table was replaced with the Schema_Migrations table that presented a list of migrations and not just the latest version number.
Looking through the Rails source, I noticed that it took the "current version" of the schema as the max version found in the Schema_Migration table.
Here's the scenario I'm trying to figure out:
Developer A generates a new script: 20090729120000_test.rb.
Developer B generates a new script: 20090729130000_test.rb.
Developer B migrates his script to the database first by not specifying the version number and assuming that Developer A's script isn't added yet.
What happens when Developer A adds his script and tries to migrate to the latest version since his script version (based on the time stamp) is less than the currently applied version now?
I'm not positive, but I believe that he would have to do a "rake db:rollback" to undo the Developer B migration, then run "rake db:migrate" to do both of them in the proper order. Of course, if two developers are working independently on tables that require no integration with one another (as this case shows, since Developer B didn't have to wait for Developer A to run his migration), developer A can simply add one to the timestamp of Developer B's migration and it will be in proper order once again.
The short answer is: don't worry about it.
rake db:migrate will attempt to run any migrations that are not found in the schema_migrations table. It doesn't matter if there are newer migrations that have already been run.
If B is dependent on A and must be run in that order, then you might have a problem, but that's an issue between the developers.
Whenever I use script/generate to generate a new scaffold for a change to my Rails database, the new migration file is prepended by a datestamp (e.g. 200903140912_create_users.rb) instead of a sequence number (e.g. 004_create_users.rb).
I then have to manually change the file name to fit in with the rest of the migration files.
Does anyone know how to fix this?
System: Mac OS X Leopard 10.5.6
Rails: v2.2.2
Ruby: v1.8.6
This was introduced in Rails 2.1. According to the migrations docs, you can revert it by setting config.active_record.timestamped_migrations to false in config/environment.rb.
I'm not sure why they made the decision, but I can tell you how it's made my life easier. On a team it was common for two people to create migrations at roughly the same time. If the last production migration was 007 then both of the new ones would be 008. The second person to commit would have a headache on their hands trying to sort it out, and the timestamps make that conflict a lot less likely.
The decision was made because when people worked together on the same project they would often try to create a migration with their new changes. This would lead to the issue where two people were working on the same project making separate changes but both generating a migration with the same number. The Rails core team decided to change it to a UTC timestamp since it's way less likely (but still possible!) that two (or more) developers would be creating a migration in the same second, rather than the same sequence.
It is also worth mentioning that using the UTC timestamp helps with sequence that migrations are run when the developers might be in separate time zones.