When running migration 20170705075039 followed by 20170715131706, the
latter fails due to lingering null values in a newly non-null column—
Mysql2::Error: Invalid use of NULL value: ALTER TABLE `tracks` CHANGE `state` `state` varchar(255) DEFAULT 'new' NOT NULL
db/migrate/20170715131706_make_track_state_not_null_and_add_default_value.rb:17:in `change'
—despite having apparently converted any existing null values prior to
changing the column type. Investigation reveals that actually the
attempted conversion has had no effect, and that this can be resolved by
clearing ActiveRecord internal caches between migrations:
connection.schema_cache.clear_data_source_cache! 'tracks'
The same problem also affects running 20170705075039 followed by
20170720134353, but in that case it leads to silent data corruption as
`change_column_null` automatically converts any lingering null values.
This commit 1) clears ActiveRecord internal caches at the beginning of
each affected migration, and 2) replaces `change_column_null` with
`change_column` to reflect that no automatic conversion is intended.
The help text for the event type field is animated using a technique
unaffected by `Capybara.disable_animation`. Wait for the animation.
Resolves: #2356
Works around: #2661
As of Rails 5.1:
- Rails has built-in support for running tests within database
transactions, so Database Cleaner is no longer needed for this.
- Rails automatically shares the database connection across threads,
so transactional_capybara is no longer needed.
Changes:
- Enable `use_transactional_tests`.
- Remove transactional_capybara.
- Remove the Database Cleaner test wrapper.
This resolves:
- transactional_capybara mismanages the shared database connection,
causing the connection to falsely report as idle after the first
test. At 6 minutes (idle_timeout + reaping_frequency) into testing,
the connection is closed, causing e.g. `PG::ConnectionBad` errors.
Presumably the intent of this was to clear the database and repopulate
it with seed data. `transaction` isn't the right strategy for this; it
just rolls back any existing transactions.
data-provide="markdown-editable" is intended for inline editing of page
content à la contenteditable. When this is applied to a textarea, the
editor is loaded only after the user clicks on the field. This behavior
breaks focus and is incompatible with keyboard navigation.
Conferences.incoming is defined on the model as scope:
scope :upcoming, (-> { where('end_date >= ?', Date.current) })
Conference.past
scope :past, (-> { where('end_date < ?', Date.current) })
It used to be a partial inside #index, but having their own page
yields some extra benefits:
- Performance: Move logic from the view to the controller
- Theres' no need to go extra steps inside the :index view
- UI: Remove the extra 'Upcoming Conferences' when the system needs
to start the flow of the creation of the first user
