This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I just found out that in the upcoming Rails 2.1 release, they have changed the format of the migrations file from the old three-digit+underscore+description+rb format to one where the three digit migration number has been replaced with a UTC timecome. I tested this by running the rails freeze edge target to get the latest rails, then created some migrations. I ended up with files like 20080403225818_create_posts.rb This breaks several parts of NetBeans: - The Migrate menu. This menu was populated by matching filenames with the old filename pattern. The code internally also only handles integer-sized versions. - Migration indexing (for similar reasons, it matches migrations files by the name pattern before trying to analyze it for database table information) - Active Record completion (it pieces together the active record models by applying information indexed from each migration; these need to be processed in the right order based on the version timestamps, which until now was a simple string-comparison on length 3 strings.
Fixed in changeset http://hg.netbeans.org/main/rev/485cc6790b00 Martin or Erno, can you review the changes? (There are a lot of files in the changeset, but most of them are related to unit tests; the key changes are in MigrateAction, RubyIndexer, and RubyIndex.) Jiri, do you agree to this one for 6.1? Without this fix, when people create migrations with the upcoming Rails 2.1, none of them will show up in the Migrate menu. Furthermore, active record completion won't work for these migrations.
Can there be more than 999 (old style) migrations or there is some limit for that in Rails? Seems that capturing the version number and migration class name would fail for 1xxx_ migrations, but not sure whether that is a real problem.
It don't know if Rails places a 3-digit constraint. We probably shouldn't be hardcoded for that, even if it's really really really unlikely anybody will run into this. In any case, this bug fix doesn't make it worse, it makes it better - as of Rails 2.1 people won't be using low-numbered migrations anyway, they will always be 14 digits UTC codes and we can handle that.
Agreed, this would definitely be good to have in 6.1 - I don't know how many migrations people have in a typical Rails project, but based on my experience > 1000 database changes should not be too uncommon in a medium size app with 50-200 tables (during the whole project lifecycle). The fix looks good to me, I don't consider the problem with 3-digits in old style migrations to be something that should be addressed in 6.1.
I agree to merge the fix into release61 branch.
Fix transplanted into 6.1 as changeset 2c0ee0311541.
Verified.