What Is Db/Development_Structure.SQL in a Rails Project

What is db/development_structure.sql in a rails project?

You should not add it to your git repository.

It is a file created automatically by rails when you run migrations with your database.yml configured to connect against a mysql database.
You can view it as an alternative to schema.rb

I believe you can force rails to create it by adding in your environment.rb:

config.active_record.schema_format = :sql

When present this file is used for example by:

rake db:test:clone_structure

Edit

Relevant section in Ruby On Rails Guides.
http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you

They recommend to check it into source control on the wiki.

I personally like to keep it out of it. I like to be able to run all migrations very quickly. It is for me a good sign. If migrations become slow I feel like I am not in total control of my environment anymore. Slowness in migrations generally means I have a lot of data in my development database which I feel wrong.

However, It seems to be a matter of personal taste nowadays.
Follow your instincts on this one.

Rails generating development_structure.sql - order of dump

I ended up locating the applicable source code in github.com/rsim/oracle-enhanced and overrode structure_dump and structure_dump_db_stored_code methods in a file I plonked into config/initializers.

Out-of-sync AUTO_INCREMENT values in development_structure.sql from Rails/MySQL creates diff noise

A variant of the accepted answer is to include the following in a .rake file in lib/tasks:

Rake::Task["db:structure:dump"].enhance do
  path = Rails.root.join('db', 'structure.sql')
  File.write path, File.read(path).gsub(/ AUTO_INCREMENT=\d*/, '')
end

This has the advantage of making the change in behavior appear more intentional (as suggested by: http://edgar.tumblr.com/post/52300664342/how-to-extend-an-existing-rake-task), esp. if put into a descriptively named file (e.g. 'skip_auto_increment.rake').

What's the difference between db:test:clone, db:test:clone_structure, db:test:load, and db:test:prepare?

Very good question. Had me stumped so I dove into the rails source and pulled up database.rake. Now it's more clear:

db:test:clone is just a combination of db:schema:dump and db:test:load:
```
task :clone => %w(db:schema:dump db:test:load)
```

db:test:clone_structure uses the {rails_env}_structure.sql file:

task :clone_structure => [ 'db:structure:dump', 'db:test:purge' ] do
  # skipped some code, here's what happens for MySQL:
  ActiveRecord::Base.establish_connection(:test)
  # ...
  IO.readlines("#{Rails.root}/db/#{Rails.env}_structure.sql").join.split("\n\n").each do |table|
    ActiveRecord::Base.connection.execute(table)
  end
end

db:test:load is the same as db:schema:load, but invokes it on the test database:

task :load => 'db:test:purge' do
  ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['test'])
  # ...
  db_namespace['schema:load'].invoke
end

db:test:prepare alerts you if any migrations are pending, and if not, either runs db:test:clone_structure (using the {rails_env}_structure.sql file) or db:test:load (using the schema.rb file), depending on the schema format (this is a little confusing to me, maybe someone else can expand on it):
```
task :prepare => 'db:abort_if_pending_migrations' do
  # ...
  db_namespace[{ :sql  => 'test:clone_structure', :ruby => 'test:load' }[ActiveRecord::Base.schema_format]].invoke
end
```

Hope this clears it up! Again, going through the database.rake file is easy and will clear up any other questions you might have. That link goes to the line that is the beginning of the :test namespace.

What is the difference between rails structure.sql and schema.rb

The main difference is that schema.rb is a Ruby representation of the database, and it is generally database-agnostic. structure.sql instead is a SQL representation of the database and it depends on the specific database you selected.

You only use the structure if you have specific database features that you need and that can't be represented by the schema.rb. For example, in the past some people replaced schema.rb with structure.sql in order to use PostgreSQL JSONB fields or foreign key constraints at database level.

Both features are now supported in the migrations, therefore you don't need to switch to structure.sql anymore (in these cases).

In general, I suggest you to use the schema.rb.

Keeping track of completed migrations in rails when using config.active_record.schema_format = :sql

I tracked down the problem...

Rails ActiveRecord does append INSERT statements for each up migration at the end of the structure.sql file.

The problem wound up being a problem in the activerecord-postgis-adapter gem which overrides the db:structure:dump rake task and does not append the said INSERT statement. I submitted a pull request to fix the problem.

schema dump on legacy oracle database using db:schema:dump using rake

did you try rake --trace?

By the way Oracle legacy schemas is a small cottage industry.

http://github.com/rsim/legacy_oracle_sample.git/README.txt

http://blog.rayapps.com/2008/06/28/activerecord-oracle-enhanced-adapter-version-111-released/

http://www.oracle.com/technology/pub/articles/saternos-rails.html

http://redsquirrel.com/cgi-bin/dave/dynamic/rails.multiple.oracle.dbs.html

What Is Db/Development_Structure.SQL in a Rails Project