Hey there,
I checked out the trunk and tried running a rake migrate on my existing 1.043 db and I get a failure.  Does anyone know if it’s possible to upgrade in this fashion?  If so, I’ll try to track down the problem and hopefully submit a patch or something, but if it’s an intentional ‘feature’ I won’t spend time on it.

Thanks,
Alex

apsoto: It’s definitely not a feature! Can you let me know what db you’re using (mysql, sqlite etc) and what error rake gave you. You can get a fuller report with:

Thanks.

Attempting to post the full rake output gives me a 412 response code (Precondition Failed), so I’m going to try splitting the post, escaping the output, etc, to see what works…..

~/projects/tracks/trunk/tracks$ ruby—version
ruby 1.8.5 (2006-08-25) [i686-darwin8.8.1]

~/projects/tracks/trunk/tracks$ mysql5—version
mysql5 Ver 14.12 Distrib 5.0.27, for apple-darwin8.8.1 (i686) using
EditLine wrapper

~/projects/tracks/trunk/tracks$ rake db:migrate—trace
(in /Users/asoto/projects/tracks/trunk/tracks)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
== AddSubclassAttrToTodos: migrating ==========================================
—add_column(:todos, :type, :string, {:default=>“Immediate”, :null=>false})
  -> 0.0724s
—add_column(:todos, :show_from, :date)
  -> 0.0260s
rake aborted!
The single-table inheritance mechanism failed to locate the subclass:
‘Immediate’. This error is raised because the column ‘type’ is
reserved for storing the class in case of inheritance. Please rename
this column if you didn’t intend it to be used for storing the
inheritance class or overwrite Todo.inheritance_column to use another
column for that information.

/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:1066:in
‘instantiate_without_callbacks’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/callbacks.rb:204:in
‘instantiate’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:424:in
‘find_by_sql’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:424:in
‘collect!‘
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:424:in
‘find_by_sql’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:994:in
‘find_every’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/base.rb:415:in
‘find’
./db/migrate//008_add_subclass_attr_to_todos.rb:5:in ‘real_up’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:212:in
‘send’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:212:in
‘migrate’
/opt/local/lib/ruby/1.8/benchmark.rb:293:in ‘measure’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:212:in
‘migrate’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:335:in
‘migrate’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:330:in
‘each’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:330:in
‘migrate’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:297:in
‘up’/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/activerecord/lib/active_record/migration.rb:288:in
‘migrate’
/Users/asoto/projects/tracks/trunk/tracks//vendor/rails/railties/lib/tasks/databases.rake:4
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in ‘call’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in ‘execute’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in ‘each’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:387:in ‘execute’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:357:in ‘invoke’
/opt/local/lib/ruby/1.8/thread.rb:135:in ‘synchronize’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:350:in ‘invoke’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in ‘run’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in ‘each’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:1906:in ‘run’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/bin/rake:7
/opt/local/bin/rake:18:in ‘load’
/opt/local/bin/rake:18

For some reason I was able to get the type column in (I had some problems with the migrate task though, see the other thread). But after that, adding a next action also failed with a similar error.

Just renaming that column seemed to solve the problem.

apsoto: Thanks for your email, and glad you managed to sneak the listing past mod_security in the end (does wrapping in code tags help, by the way?)

It looks like rake or Rails has got stricter about this recently because this migration ran OK for me when I first upgraded my db when we added it. There’s something a bit funny going on, because the column ‘type’ is being used for single table inheritance in this instance. Possibly it’s because we’ve got rid of that single table inheritance, so it can’t find the subclass.

As I said, we’ve changed this now, so the migration is defunct, but like murdering your own grandfather if you’re a time-traveller, changing old migration files after the fact is fraught with unforeseen consequences! We’ll have to think how to handle this. As lukemelia said in another thread, it probably makes sense to schema.rb for people who are jumping straight from the last stable release to the newest stable release (when we release it…)

Thanks for the response.  The way I got it past mod security was to remove any periods (.).

IMO I agree with you on not going back and changing migrations but in this case (which I’ve experienced myself on projects) a broken migration _should_ be fixed, otherwise, you’ll never be able to run migrate from the broken version and past.

This is probly better discussed on a dev list, but I’d suggest maybe since things are broken, that it’s time to make some backwards compatibility breakage and reset the migrations to 1 or fix the broken migration.  Having broken migrations really breaks some of their usability.  For dev purposes I love being able to blow away the db and recreating from scratch.  But that’s just my opinion

Hi

does this mean that ticket #407 can be closed?

http://dev.rousette.org.uk/ticket/407

apsoto: I think I agree. We’ve got to try to improve installation/upgrading before the new release anyway, so I’ll fix it then.

Reinier Balt: I’ll leave it open until I actually fix it