3 ms·

* Improved migration format: make it possible to create new initial migrations as a project evolves by rebasing. Meaning there's no need to keep or execute the

* Improved migration format: make it possible to create new initial migrations as a project evolves by rebasing. Meaning there's no need to keep or execute the whole migration history every time. On my current project running migrations from starch takes 30mins :( * Improvement in performance in regarding to JSON generation or other thing is always welcome. following benchmarks can be taken as reference where rails stands currently. Any improvement in the above stats would be awesome http://www.techempower.com/benchmarks/#section=data-r6 http://www.techempower.com/benchmarks/#section=data-r6

steveklabnik 13y ago
I have seen people sorta 'merge up' migrations at a point in time... As for JSON generation, there's an open ticket for it already: https://github.com/rails/rails/issues/9212 https://github.com/rails/rails/issues/9212
jordanthoms 13y ago
Shouldn't you be using schema:load or structure:load rather than running your migrations from scratch? Migrations are for a database which already has data.
cheald 13y ago
The oj gem helps json generation a ton. The circular reference checks are still slow though.
- phamilton 13y ago
  In my tests, serialization to a hash before oj writes it out to json is the slowest part. Doing 1000 records (~30 entries each, some with nested entries) to json via OJ and as_json results in less than 20% spent in OJ and the other 80% in generating the hash.
cheald 13y ago
The oj gem helps json generation a ton. The circular reference checks are still slow though.
jph 13y ago
+1 for this. My team "rolls up" migrations akin to spring cleaning, because the migration files often have more important information that the db schema, and are easier for team members to learn quickly. I'll contribute $50 if this feature is accepted for Rails 4.1.
- steveklabnik 13y ago
  > I'll contribute $50 if this feature is accepted for Rails 4.1. Oh yeah? I wonder if others would also pay for bug bounties.
  - codeodor 13y ago
    I came across https://www.bountysource.com/ https://www.bountysource.com/ the other day.

steveklabnik 13y ago

I have seen people sorta 'merge up' migrations at a point in time... As for JSON generation, there's an open ticket for it already: https://github.com/rails/rails/issues/9212 https://github.com/rails/rails/issues/9212

jordanthoms 13y ago

Shouldn't you be using schema:load or structure:load rather than running your migrations from scratch? Migrations are for a database which already has data.

cheald 13y ago

The oj gem helps json generation a ton. The circular reference checks are still slow though.

phamilton 13y ago
In my tests, serialization to a hash before oj writes it out to json is the slowest part. Doing 1000 records (~30 entries each, some with nested entries) to json via OJ and as_json results in less than 20% spent in OJ and the other 80% in generating the hash.

cheald 13y ago

The oj gem helps json generation a ton. The circular reference checks are still slow though.

jph 13y ago

+1 for this. My team "rolls up" migrations akin to spring cleaning, because the migration files often have more important information that the db schema, and are easier for team members to learn quickly. I'll contribute $50 if this feature is accepted for Rails 4.1.

steveklabnik 13y ago
> I'll contribute $50 if this feature is accepted for Rails 4.1. Oh yeah? I wonder if others would also pay for bug bounties.
- codeodor 13y ago
  I came across https://www.bountysource.com/ https://www.bountysource.com/ the other day.