No created_on / updated_on after migration
Added by Michael Tenschert about 14 years ago
Hello!
I just migrated from Trac 0.12.1 to Redmine 1.0.3 (according to official wiki).
Everything worked fine, but when I want to visit an issue ( http://project.websitebaker-dev.de/projects/wb2/issues ) it gives 500 Internal error back.
The migration was from SQlite3 database to MySQL 5 UTF-8.
"created_on" and "updated_on" fields inside "issues" seem to be false, they display "NULL" or "0000-00-00 00:00:00". But it would be nice that dates could be migrated, too... Before a trac 0.12 -> Redmine 1.0.1 migration on very same server didn't have that problems.
The log says:
ActionView::TemplateError (undefined method `-' for nil:NilClass) on line #12 of app/views/issues/show.rhtml: 9: <%= render_issue_subject_with_tree(@issue) %> 10: </div> 11: <p class="author"> 12: <%= authoring @issue.created_on, @issue.author %>. 13: <% if @issue.created_on != @issue.updated_on %> 14: <%= l(:label_updated_time, time_tag(@issue.updated_on)) %>. 15: <% end %> app/helpers/application_helper.rb:308:in `time_tag' app/helpers/application_helper.rb:304:in `authoring' app/views/issues/show.rhtml:12:in `_run_rhtml_app47views47issues47show46rhtml' app/controllers/issues_controller.rb:110:in `show' app/controllers/issues_controller.rb:109:in `show' passenger (2.2.15) lib/phusion_passenger/rack/request_handler.rb:92:in `process_request' passenger (2.2.15) lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop' passenger (2.2.15) lib/phusion_passenger/railz/application_spawner.rb:441:in `start_request_handler' passenger (2.2.15) lib/phusion_passenger/railz/application_spawner.rb:381:in `handle_spawn_application' passenger (2.2.15) lib/phusion_passenger/utils.rb:252:in `safe_fork' passenger (2.2.15) lib/phusion_passenger/railz/application_spawner.rb:377:in `handle_spawn_application' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:352:in `__send__' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:163:in `start' passenger (2.2.15) lib/phusion_passenger/railz/application_spawner.rb:222:in `start' passenger (2.2.15) lib/phusion_passenger/spawn_manager.rb:253:in `spawn_rails_application' passenger (2.2.15) lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add' passenger (2.2.15) lib/phusion_passenger/spawn_manager.rb:247:in `spawn_rails_application' passenger (2.2.15) lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize' passenger (2.2.15) lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize' passenger (2.2.15) lib/phusion_passenger/spawn_manager.rb:246:in `spawn_rails_application' passenger (2.2.15) lib/phusion_passenger/spawn_manager.rb:145:in `spawn_application' passenger (2.2.15) lib/phusion_passenger/spawn_manager.rb:278:in `handle_spawn_application' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:352:in `__send__' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:352:in `main_loop' passenger (2.2.15) lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously' Rendering /home/redmine/public/500.html (500 Internal Server Error)
Thanks very much!
Replies (4)
RE: No created_on / updated_on after migration - Added by Michael Tenschert about 14 years ago
A few more informatio about it...
That's the SSH log when using rake redmine:migrate_from_trac RAILS_ENV="production" --trace
Migrating wiki........................................................................................................................................................................................................................................................................................................................................................................................rake aborted! no implicit conversion to float from nil /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/time/calculations.rb:277:in `minus_without_duration' /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/time/calculations.rb:277:in `minus_without_coercion' /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/time/calculations.rb:286:in `-' /home/redmine/lib/tasks/migrate_from_trac.rake:79:in `fake' /home/redmine/lib/tasks/migrate_from_trac.rake:582:in `migrate' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_collection.rb:369:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:215:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:215:in `each' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:215:in `send' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_proxy.rb:215:in `method_missing' /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/associations/association_collection.rb:369:in `method_missing' /home/redmine/lib/tasks/migrate_from_trac.rake:580:in `migrate' /home/redmine/lib/tasks/migrate_from_trac.rake:765 /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain' /usr/local/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run' /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 /usr/local/bin/rake:19:in `load' /usr/local/bin/rake:19
And my gem list --local
actionmailer (2.3.8, 2.3.5, 2.1.2) actionpack (2.3.8, 2.3.5, 2.1.2) activerecord (2.3.8, 2.3.5, 2.1.2) activeresource (2.3.8, 2.3.5, 2.1.2) activesupport (2.3.8, 2.3.5, 2.1.2) fastthread (1.0.7) i18n (0.4.1) mocha (0.9.8) mysql (2.8.1) passenger (2.2.15) rack (1.2.1, 1.1.0, 1.0.1) rails (2.3.8, 2.3.5, 2.1.2) rake (0.8.7) rubygems-update (1.3.7) shoulda (2.10.3) sqlite3-ruby (1.3.1) thoughtbot-shoulda (2.10.2)
RE: No created_on / updated_on after migration - Added by Michael Tenschert about 14 years ago
Sorry for tripleposting... I also followed closely that steps: http://www.redmine.org/boards/2/topics/18087
lft, rgt and root_id updates also returned "0 rows", so that's working.
Is it perhaps related with that?
http://trac.edgewall.org/wiki/TracUpgrade
Microsecond timestamps All timestamps in database tables (except the session table) have been changed from "seconds since epoch" to "microseconds since epoch" values. This change should be transparent to most users, except for custom reports. If any of your reports use date/time columns in calculations (e.g. to pass them to datetime()), you must divide the values retrieved from the database by 1'000'000. Similarly, if a report provides a calculated value to be displayed as a date/time (i.e. with a column named "time", "datetime", "changetime", "date", "created" or "modified"), you must provide a microsecond timestamp, that is, multiply your previous calculation with 1'000'000.
Sorry, I'm no Ruby neither Python programmer, I don't know how to have a closer look to that issue.
RE: No created_on / updated_on after migration - Added by Félix Delval about 14 years ago
Hello I encountered the same problem. It seems that the script is unable to extract the dates from the trac database, this lead to an error/excetion with the time transformation function that fail when given nil as an argument.
I opened a ticket here : http://www.redmine.org/issues/6868
RE: No created_on / updated_on after migration - Added by Leo Shklovskii over 12 years ago
Felix's problem is unrelated, but also needed for Trac .12. Michael is right, the culprit is the change of date storage from seconds to microseconds. To fix it, go through the trac migration script - lib/tasks/migrate_from_trac.rake - and everywhere there is a:
Time.at(foo)
change it to:
Time.at(0,foo)