Error when adding new boolean CRUD field

[Michael Holroyd]

This logic seems wrong for new CRUD fields. It's looking for the boolean in the original create_students migration instead of in the new add_field_to_students migration:

bullet_train-core/bullet_train-super_scaffolding/lib/scaffolding/transformer.rb

Lines 1269 to 1288 in 8d08383

 if boolean_buttons 
   # Give priority to crud-field migrations if they exist. 
   add_column_reference = "add_column :#{class_names_transformer.table_name}, :#{name}" 
   create_table_reference = "create_table :#{class_names_transformer.table_name}" 
   confirmation_migration_file_name = `grep "#{add_column_reference}" db/migrate/*`.split(":").first 
   confirmation_migration_file_name ||= `grep "#{create_table_reference}" db/migrate/*`.split(":").first 
  
   old_line, new_line = nil 
   File.open(confirmation_migration_file_name) do |migration_file| 
     old_lines = migration_file.readlines 
     old_lines.each do |line| 
       target_attribute = line.match?(/:#{class_names_transformer.table_name}, :#{name}, :boolean/) || line.match?(/\s*t\.boolean :#{name}/) 
       if target_attribute 
         old_line = line 
         new_line = "#{old_line.chomp}, default: false\n" 
       end 
     end 
   end 
   replace_in_file(confirmation_migration_file_name, old_line, new_line) 
 end 

old_line and new_line are nil since the boolean is not in the original migration, which causes a crash:

Replacing in 'db/migrate/20230628195752_create_students.rb'.
rake aborted!
TypeError: no implicit conversion of nil into String
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:574:in `gsub!'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:574:in `replace_in_file'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:1318:in `block in add_attributes_to_various_views'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:663:in `each'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:663:in `each_with_index'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/transformer.rb:663:in `add_attributes_to_various_views'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/bullet_train/super_scaffolding/scaffolders/crud_field_scaffolder.rb:32:in `run'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/scaffolding/script.rb:107:in `<main>'
<internal:/Users/meekohi/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/Users/meekohi/.rvm/rubies/ruby-3.2.2/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/zeitwerk-2.6.8/lib/zeitwerk/kernel.rb:38:in `require'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/bullet_train/super_scaffolding.rb:25:in `run'
/Users/meekohi/.rvm/gems/ruby-3.2.2/gems/bullet_train-super_scaffolding-1.2.26/lib/tasks/bullet_train/super_scaffolding_tasks.rake:10:in `block (2 levels) in <main>'
Tasks: TOP => bullet_train:super_scaffolding
(See full trace by running task with --trace)

It also seems incorrect to me to ever go back and rewrite an old migration like this -- presumably these have already been run and changing them could create issues with rolling back or finding your current database doesn't reflect the old migrations anymore.

[Gabriel Arcangel Zayas]

@Meekohi

add_column_reference = "add_column :#{class_names_transformer.table_name}, :#{name}"
create_table_reference = "create_table :#{class_names_transformer.table_name}"
confirmation_migration_file_name = `grep "#{add_column_reference}" db/migrate/*`.split(":").first
confirmation_migration_file_name ||= `grep "#{create_table_reference}" db/migrate/*`.split(":").first

This bit SHOULD be prioritizing the add_column which should be the very last migration done in the flow of super scaffolding, but I agree with you that it shouldn't be in the create_table line, so we should probably remove those altogether.

Since we merged #285 it should be working when we release v1.2.27. Will see if I can look over the create_table logic in the meantime.

[Michael Holroyd]

Awesome tbh I think I was looking at my local version which is pre #285 and just copy/pasted the mess without noticing that update. I could see some weird side-cases (a field that is added, removed, then added again) but the post #285 version makes sense to me. I'm not sure what a full proper solution would be, seems like it'd need to know how far back was "ok" to look in the migrations (or maybe limit itself to only the most recent one? unclear...)

[Jeremy Green]

@Meekohi and @gazayas, do y'all think there's anything more to be done on this one?

[Michael Holroyd]

Yea lets close this for now -- I think it'd be a good idea to restructure things to rigorously ensure old migration don't get touched but that's a different idea than this issue. Thanks!