Either I didn't get your point or you don't know what what Rails migrations are. Migrations are just a way to "change the database" in a repeatable way.
Right, but the grandparent's complaint was that you had to change your model, then write migrations to match.
In other frameworks, you use your tool of choice to change the database schema, then build the project and you're done. All the "model" stuff regenerates automatically. Thus, schema/model changes have no pain associated with them whatsoever, so there's no particular advantage to using nosql vs sql.
With Rails' ActiveRecord the model introspects the database schema at run time and figures out field changes automatically. What it doesn't figure out is relations and you still have to specify them in both the database schema and the model. Since you're mentioning project build, I suppose you're referring to Java or C# frameworks. Are those frameworks able to generate code for relations as well? (I suppose this requires following naming conventions or setting referential constraints)
Yeah, conventions cover pretty much every case you tend to come across. Got a column called CompanyID that has a foreign key constraint over to the Company table? Perhaps this is a relation... Nice of Rails to make it acceptable to simply ask you to name your stuff in a consistent way so that things just work.
The added bonus of a build step is that you don't need to keep regenerating the same classes and SQL code every page load, but it's not really any different from the programmer's standpoint.
In other frameworks, you use your tool of choice to change the database schema, then build the project and you're done. All the "model" stuff regenerates automatically. Thus, schema/model changes have no pain associated with them whatsoever, so there's no particular advantage to using nosql vs sql.