Generate view definition and migration for updates

[calebhearth]

rails generate view_update searches <= or the like

• Creates app/views/searches_v2.sql, assuming only one preexisting version. (calculate next version)
• creates db/migrate/..._update_searches_v2.rb

[derekprior]

I think we had planned to re-use rails generate scenic:view searches which would be smart enough to check if searches_v1.sql already exists and adding v2 if it does.

Alternative: rails generate scenic:update searches

[calebhearth]

Either are fine with me.

[derekprior]

If I have db/views/searches_v2.sql but have removed v1 - what file gets added? Do I create v1? Or do I detect that v2 is already there and increment to v3?

Should the versioning use the timestamp like migrations to avoid even having to think of this? The obvious downside there is that it's a lot more work to figure out what to put in revert_to unless we default it.

[derekprior]

... and even if we default it, it's still a real pain to figure out what to override it with. The files would still sort sanely (which they actually won't with our current naming scheme (v1, v10, v11, v2, ...).

[calebhearth]

Seems fairly simple to me:

%w(foo_v2.sql foo_v10.sql)
  .map { |name| /v(?<version>\d+)\.sql$/.match(name)["version"].to_i }
  .max.next

[calebhearth]

I'm also happy to pad versions, but my guess is that they'll rarely get above 9, let alone 99.

[derekprior]

Closed by #33.