Drop Sessions Table and Delete lib/tasks/sessions.rake

[aaronskiba]

Fixes #723

Changes proposed in this PR:

• Drop sessions table from the app's db
  • Within config/initializers/session_store.rb, the app has been configured to use cookie_store for quite some time now. The sessions table has not been used since this change has occurred.
• Delete lib/tasks/sessions.rake
  • This file's rake task was created to clear the sessions table / prevent it from becoming overpopulated. However, because the sessions table is no longer used, this rake task is no longer needed. In addition, this rake task is currently broken: https://app.rollbar.com/a/ualbertalib/fix/item/dmp_assistant/490
• To go along with these codebase changes, the cronjob for rake sessions:cleanup can be removed from all environments (production, staging, and sandbox).

[aaronskiba]

The failing MySQL actions are expected behaviour after running the PR within this migration.

[aaronskiba]

This PR’s migration is meant to simply drop the sessions table:

class DropSessionsTable < ActiveRecord::Migration[6.1]
  def up
    drop_table :sessions
  end

Unfortunately, it is really transforming the db/schema.rb file: 124bc52#diff-cbf8b25d6d853acf58fa9057841f407d29ffe90649c75cf9e3f51b2d6e3aa1d3
Which in turn is breaking the MySQL workflows. Multiple errors like the following are thrown:

ActiveRecord::MismatchedForeignKey: Column `org_id` on table `annotations` does not match column `id` on `orgs`, which has type `bigint unsigned`. To resolve this issue, change the type of the `org_id` column on `annotations` to be :bigint. (For example `t.bigint :org_id`).
18
Original message: Mysql2::Error: Referencing column 'org_id' and referenced column 'id' in foreign key constraint 'fk_rails_aca7521f72' are incompatible.

This error is occurring because the primary keys are being changed from type :integer to type :serial. The primary key type was never specified in some of these older migrations and a Rails upgrade must be responsible for the change in the default type. However, unlike the primary key, the foreign key was in fact specified as type integer.

There must be a difference in how MySQL vs PostgreSQL interpret the serial type. The primary_key :serial <-> foreign_key :integer works with PostgreSQL, but breaks with MySQL.

The db/schema.rb file is auto-generated and not meant to be physically altered. I had tested out migrations in the past and always encountered this same behaviour. I reached out to the upstream developers. One of them admitted that they had always been physically altering the file to keep the MySQL workflows working.

We discussed it a bit and it sounds like all of the various upstream developers are okay with ditching the MySQL workflows; I guess everyone is using PostgreSQL. The Rails 7 upgrade also currently includes some migrations that would also result in the MySQL workflows breaking.

[lagoan]

Good job Aaron. I like the way you made the sessions migration reversible.

[lagoan]

LGTM!