More standard engine config #65
Conversation
|
Which version of rails is this targeting? I think this supports 4.2.6 if we change the documentation for the migration command to Also, this is a breaking change for anyone seeking to upgrade from something like 0.8 to this version. I'm okay with that since we're not yet at 1.0. Maybe just a quick note in the readme along the lines of an upgrade path like 0.8 -> 0.12.2 -> 0.13 or something Thanks!! |
|
@mbulat sorry - I missed this somehow! The binstub is not required for Rails 5 - that's just for development. When the developer of the gem calls Sure, I'll add the breaking change note. |
d1eefb3 to
c1f28c0
Compare
So that we can generate migration files the way Rails guides suggests
c1f28c0 to
28567e3
Compare
This is the typical configuration of an Rails engine
7c66bb0 to
f15c00e
Compare
|
@mbulat what do you think of this change? |
f15c00e to
a2b678a
Compare
Keep tenant column: Until we merge the feature that always turns on tenancy (mbulat#79), we must keep the dummy Rails app's migrations disjoint from what `rake plutus:migrations:install` actually copies over
d3de0bf to
b7524d0
Compare
b7524d0 to
56035ad
Compare
Makes the configuration of the gem a little bit more like the standard way. Main highlight:
Engine migration files are generated with
rails g migration .... This allows for future changes to the db to be handled by Rails (detects which migrations are not there), so that the developer won't need to run specialrails g plutus:upgradecommands.Note: Keep tenant column in the dummy app. Until we merge the feature that always turns on tenancy
(#79), we must keep the dummy Rails app's migrations disjoint from what
rake plutus:migrations:installactually copies over