#578 ✓not-applicable
Jamie Macey

migrations don't respect repository()

Reported by Jamie Macey | September 26th, 2008 @ 11:50 AM

In a migration's up block,

repository(:stats) do
  create_table :profile_stats do

creates the profile_stats table in the development repository, not the stats repository as defined in the config file.

Comments and changes to this ticket

  • Paul Sadauskas (Rando)

    Paul Sadauskas (Rando) September 26th, 2008 @ 05:55 PM

    • Assigned user changed from “Sam Smoot” to “Paul Sadauskas (Rando)”
    • State changed from “new” to “hold”

    For now, a single migration can only operate on a single database/repository, and they are tracked separately. To change the db for the migration, pass it in as an option:

    migration 1, :create_profile_stats_table :database => :stats do
      create_table :profile_stats do

    Support for the repository block would be neat, but at first glance would probably be hard to implement. Maybe supporting something like:

    repository(:foo) { migration 1, :bar do ... }

    would be better. I don't know what the 'hold' ticket status is for, but thats what I'll set it as for now.

  • Jamie Macey

    Jamie Macey September 30th, 2008 @ 01:18 PM

    Adding :database => :stats to my migration does what I was wanting to get done.

    Perhaps a terminology change would help other people confused by this? In the models you need default_repository_name, or use a repository(:foo) block, or pass :repository => :foo in the query, but migrations use :database for no particularly good reason (other than matching internal instance variables)

  • Paul Sadauskas (Rando)

    Paul Sadauskas (Rando) September 30th, 2008 @ 02:41 PM

    Yeah, dm-migrations was written before dm-core changed the name from database to repository, and I just haven't gotten around to renaming everything.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) December 4th, 2008 @ 04:09 AM

    Rando, I'm not sure if you're working on this or not, but if you are, can you change the ticket status to "accepted". That way we can tell the difference between tickets that are actively being worked on, or in limbo and re-assign them if necessary.

  • Paul Sadauskas (Rando)

    Paul Sadauskas (Rando) December 4th, 2008 @ 01:20 PM

    • State changed from “hold” to “accepted”
  • Piotr Solnica (solnic)

    Piotr Solnica (solnic) March 24th, 2011 @ 07:21 AM

    • State changed from “accepted” to “not-applicable”
    • Milestone order changed from “0” to “0”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »