This project is archived and is in readonly mode.

#4721 ✓stale

schema dump does not respect autoincrement

Reported by Leigh | May 28th, 2010 @ 09:57 PM

I created a table with the following migration:

create_table "stops", :force => true, :options => "auto_increment = 5" do |t|

t.integer  "user_id",                      :default => 0,     :null => false
t.integer  "origin_id",                    :default => 0,     :null => false
t.datetime "created_at",                                      :null => false
t.datetime "accepted_at"


However, db:schema:dump clobbers the :options => "auto_increment = 5" portion of it in my schema.rb.

Comments and changes to this ticket

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:52 PM

    • State changed from “new” to “open”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:52 PM

    • State changed from “open” to “stale”
  • Leigh

    Leigh February 2nd, 2011 @ 06:38 PM

    It is absolutely still reproducible with Rails 3.0.3. I simply did the exact same steps as above and got the same result. However, we have gotten around this problem of not being able to specify custom MySQL options in Rails migrations by completely circumventing using Rails migrations in our production environment - we use our own custom migration rake task. It was not something we were happy with having to do, but it allows us to optimize and streamline our migrations anyway, which is important with as much data as we have in production. Thus, I will not petition to re-open this issue. You are aware of it, and it's up to you guys to prioritize based on your load and resources.

  • bingbing

Create your profile

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

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

People watching this ticket