Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Update for RefineryCMS 2.0.0 #56

Merged
merged 9 commits into from
+1,854 −1,787

5 participants

@robyurkowski
Collaborator

To be perfectly clear, this is not ready to be pulled yet (though it is very close). I mucked something up or didn't namespace the InquirySettings yet, so you can't change who is notified. But I wanted to open this pull request initially so someone else doesn't go gallivanting off, tilting at windmills like I have here.

I'm hoping to fix the rest of this real quick tomorrow morning.

@robyurkowski
Collaborator

Okay. This should be ready to go.

@ugisozols ugisozols commented on the diff
db/migrate/20101208082840_create_inquiries.rb
@@ -1,23 +1,21 @@
class CreateInquiries < ActiveRecord::Migration
def up
- unless ::Refinery::Inquiry.table_exists?
- create_table ::Refinery::Inquiry.table_name, :force => true do |t|
+ unless ::Refinery::Inquiries::Inquiry.table_exists?
+ create_table :refinery_inquiries_inquiries, :force => true do |t|
@ugisozols Owner

We failed to think through this namespacing stuff because it just doesn't make sense to have table named refinery_inquiries_inquiries.

@robyurkowski Collaborator

Actually, this is a bad example to look at. It's a lot more poignant and helpful when you get into things like the portfolio -- then you have a table like :refinery_portfolio_entries.

@ugisozols Owner

Yeah it totally makes sense when engine has more than one model but imho we need to come with solution when there's only one model.

@robyurkowski Collaborator

IMO, better to be consistent -- if you have to inspect the database, you should be able to see refinery__. Keep in mind that in this engine, we could have called Inquiries simply Contacts. It's only by basis of the name of the resource that it looks funny.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@ugisozols
Owner

Great work @robyurkowski :heartpulse:

@ugisozols ugisozols merged commit 280db3e into refinery:rails-3-1
@dmoose

This commit breaks existing code without warning since it replaces the migration with a new one with a different table name but the migration name remains the same so it will not even replace the existing migration.

There should be more thought given to this. At least some sort of warning, but it would seem to make a lot more sense to continue to use the old table name.

Collaborator

I understand your frustration, but before the release of Refinery 2.0, we are trimming migrations all over the code-base, since it is not considered backward compatible, and now is the only legitimate time to clean up the migrations. I'm sorry if it's caused issues with any existing sites you have, but the unstable branch is somewhat unstable.

We're using the new table name because it is standard with the new namespacing format. It seems odd, perhaps, that it should be named refinery_inquiries_inquiries, but it follows the general pattern of refinery_<engine>_<model>. People have suggested renaming the Inquiry model to something else like Contact, and I believe @parndt and @ugisozols have both expressed a willingness to merge a pull request with this change.

Do you guys have any plans for how the migration changes will be handled for those upgrading from refinery 1.0? I've been using edge, so I expect that things will break unexpectedly, but others could be taken by surprise by this once 2.0 is released.

Owner
Collaborator

Please feel free to contribute to the changelog. Nobody adds anything to it because nobody knows it's there (something I plan on rectifying).

I agree in principle that we need a way to update between the two versions. I think maybe in this mode, @parndt, we should designate 2.0 as a transitionary release for migrations—just generate new ones that rename tables as dmoose suggests, and issue a warning—and hold off the clean-up to 2.1 or even 3.0. I'd like it clean for 2.0, but if we do want to give people a way to update their apps, this is somewhat necessary, I think.

Owner
Collaborator

My personal inclination is that there's too little time between a 1.1 release and a 2.0 release to bother. If we keep migrations messy — add a few more in, even, to manage the transition — then we don't need to force users to update twice to get to 2.0.

@parndt

@robyurkowski this should just be called SettingsController now

Collaborator

Sheesh, Phil. You're only 19 days late.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 3, 2012
  1. Begins mass update to new namespacing.

    Rob Yurkowski authored
  2. Adds guardfile and fixes specs.

    Rob Yurkowski authored
  3. Corrects locale stuff and fixes final specs.

    Rob Yurkowski authored
  4. Moves inquiries generator into proper spot.

    Rob Yurkowski authored
  5. Adds missing question mark.

    Rob Yurkowski authored
  6. Appends missing .rb.

    Rob Yurkowski authored
  7. Fixes spec (used old inquiry_settings path).

    Rob Yurkowski authored
  8. Strip debugging save_and_open_page from spec.

    Rob Yurkowski authored
Something went wrong with that request. Please try again.