I agree, that's what I had in mind too . How about a config named
generate_schema_after_migration which holds true/false. It could be true
by default, and you can override the default behavior by setting it to
false in `config/environments/production.rb`. I am ready to work on this if
I get a
I agree, test environment should not evolve the schema, instead depend on
an existing schema. So I think it makes sense not to generate schema if at
all I choose to run migrations in the test environment.
On 4 February 2014 17:16, Xavier Noria f...@hashref.com wrote:
On Tue, Feb 4, 2014 at
I've sent a PR for this. Please give it a look :
https://github.com/rails/rails/pull/13948
On 4 February 2014 17:21, Emil S emil.so...@gmail.com wrote:
I agree, test environment should not evolve the schema, instead depend on
an existing schema. So I think it makes sense not to generate
:39, Seth Faxon seth.fa...@gmail.com wrote:
I occasionally run diff's on the production schema.rb or structure.sql
against what is in git to be sure development environments are staying in
sync with production.
On Fri, Jan 31, 2014 at 10:13 AM, Emil S emil.so...@gmail.com wrote:
Currently
Currently the `db:migrate` rake task runs `dump` at the end which dumps the
database structure to `schema.rb` / `structure.sql`. This will be useful in
development environment but I can't see a reason why this should run in
production environment. Removing this step in production would make
Apologies if the question is too naive.
When I create a new engine using `rails plugin new engine_name`, I can
see a default dependency on rails in gemspec. Engines such as devise only
have dependency on railties and not the whole of rails.
Why is the default dependency rails and not railties ?
