CDB-2999 Required files for running migration

pull/475/head
Kartones 10 years ago
parent 0ad011d64e
commit e38698970e

@ -1,9 +1,14 @@
2.14.1 (XXXX-XX-XX)
-------------------
* New features
* Upgraded UPGRADE doc and required rakes to run
* Added new rake: populate_new_fields
* Added user_id to Visualization Model
* Fixed bugs
* Migration Type (see UPGRADE): Mandatory migration
2.14.0 (2014-05-20)
-------------------

@ -1,20 +1,26 @@
There's no standard procedure to migrate from one version to another of
the rails application, so version specific procedures are documented
in the NEWS.md file.
In absence of specific instructions, after upgrading the rails code to
<version>, you must upgrade existing databases using these commands:
NOTES:
- Redis server must be listening on the configured
port (see config/app_config.yml) for some of the
steps below to work
- Rails must be restarted after an upgrade
Standard migration (default)
----------------------------
Unless stated otherwise, assume any new CartoDB release requires calling these commands:
$ bundle exec rake db:migrate
$ bundle exec rake cartodb:db:load_functions
$ bundle exec rake cartodb:db:load_triggers
$ bundle exec rake cartodb:db:create_schemas
$ bundle exec rake cartodb:db:migrate_to[<version>]
NOTE: redis server must be listening on the configured
port (see config/app_config.yml) for some of the
steps above to work
Rails must be restarted after an upgrade
Mandatory migration
-------------------
Versions marked at the NEWS.md as requiring this migration must run all this commands:
$ bundle exec rake db:migrate
$ bundle exec rake cartodb:db:populate_new_fields
$ bundle exec rake cartodb:db:load_functions
$ bundle exec rake cartodb:db:load_triggers
$ bundle exec rake cartodb:db:create_schemas

@ -0,0 +1,9 @@
Sequel.migration do
up do
add_column :visualizations, :user_id, :uuid
end
down do
drop_column :visualizations, :user_id
end
end

@ -412,5 +412,39 @@ namespace :cartodb do
end
end
# New UPGRADE step, whose purpose is populate fields added by Rails migrations.
# Motivation: some field populations can be error-prone, time consuming, etc.,
# so better to leave each the responsability of try-catching or not.
# Initially it'd be nice if all populations are done via pure SQL queries,
# so this rake can be called in a branch that still has no Model changes
# and doesn't breaks the application
desc 'populates db new fields after certain migrations'
task :populate_new_fields => :environment do
# 2.14.1
execute_on_users_with_index(:populate_new_fields.to_s, Proc.new { |user, i|
user.db.execute(%Q{
UPDATE visualizations
SET user_id = maps.user_id FROM maps
WHERE maps.user_id='#{user.id}'
AND visualizations.user_id IS NULL
AND visualizations.map_id = maps.id
})
})
end #populate_new_fields
# Executes a ruby code proc/block on all existing users, outputting some info
# @param task_name string
# @param block Proc
def execute_on_users_with_index(task_name, block)
count = User.count
puts "Running #{task_name} for #{count} users"
User.all.each_with_index do |user, i|
puts "#{user.id} #{i}"
block.call(user, i)
end
puts "Finished #{task_name}"
end #execute_on_users_with_index
end
end

Loading…
Cancel
Save