Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Migrations on multiple shards broken in rails 3.2 #110

Closed
NielsKSchjoedt opened this Issue · 6 comments

3 participants

@NielsKSchjoedt

When doing a migration e.g.:

class AddIndexToFailedAdvertsCreatedAt < ActiveRecord::Migration
  using_group(:shards)

  def change
    add_index :failed_adverts, :created_at
  end
end

It only adds the migration-id (schema-migrations) to the database that is set as master-shard, unless I use the changes made in this fork:
https://github.com/Agilysys/octopus

BTW i'm on 3.2.6 and my shards.yml looks like this:

octopus:
  verify_connection: true
  environments:
    - development
    - production
  development:
    shards:
      da:
        adapter: postgresql
        encoding: utf8
        database: dk_development
        username: postgres
        password: postgres
        template: template0 # Required for UTF8 encoding
        pool: 25
      se:
        adapter: postgresql
        encoding: utf8
        database: se_development
        username: postgres
        password: postgres
        template: template0 # Required for UTF8 encoding
        pool: 25
@sobrinho
Collaborator

@NielsKSchjoedt do you know if that also happens on rails 2?

@NielsKSchjoedt

I don't know about rails 2, but I know it worked when I was on rails 3.1 :-)

@NielsKSchjoedt

Any news? I just discovered that the rake db:migrate:down is broken in this branch https://github.com/Agilysys/octopus, it only migrates on one of my databases. So I can't even use that one anymore :-( I would really like to get back on the master if just things were behaving :-)

@NielsKSchjoedt

Hmm, I just discovered, that the issue with the migration ids not being added to the schema_migrations table seems to only occur to the last shard in the last migration (if you run several at a time). Let's say I have two migrations that I need to run (A and B) and two databased to run them on (DBA and DBB) then it seems that the only id not being added is B to DBB's schema_migrations...

@ragalie
Collaborator

The logic that adds/deletes version numbers from the schema_migrations table isn't wrapped in an Octopus.using block. It should be writing to the database listed in database.yml for your environment.

I agree that it would be better to write the version numbers to all databases, but that's not the currently expected functionality.

@sobrinho
Collaborator

Closing since #143 changed this behavior.

@sobrinho sobrinho closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.