Skip to content

Commit

Permalink
Fix column type for job_id foreign keys in executions tables
Browse files Browse the repository at this point in the history 
No idea how this ended up as `integer`. The initial tables were created
via a migration using `t.references`.
  • Loading branch information
@rosa
rosa committed Sep 6, 2024
1 parent d273261 commit 4667002
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions lib/generators/solid_queue/install/templates/db/queue_schema.rb
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
ActiveRecord::Schema[7.1].define(version: 2024_09_04_193154) do
create_table "solid_queue_blocked_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.string "queue_name", null: false
t.integer "priority", default: 0, null: false
t.string "concurrency_key", null: false
Expand All @@ -12,15 +12,15 @@
end

create_table "solid_queue_claimed_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.bigint "process_id"
t.datetime "created_at", null: false
t.index [ "job_id" ], name: "index_solid_queue_claimed_executions_on_job_id", unique: true
t.index [ "process_id", "job_id" ], name: "index_solid_queue_claimed_executions_on_process_id_and_job_id"
end

create_table "solid_queue_failed_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.text "error"
t.datetime "created_at", null: false
t.index [ "job_id" ], name: "index_solid_queue_failed_executions_on_job_id", unique: true
Expand Down Expand Up @@ -65,7 +65,7 @@
end

create_table "solid_queue_ready_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.string "queue_name", null: false
t.integer "priority", default: 0, null: false
t.datetime "created_at", null: false
Expand All @@ -75,7 +75,7 @@
end

create_table "solid_queue_recurring_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.string "task_key", null: false
t.datetime "run_at", null: false
t.datetime "created_at", null: false
Expand All @@ -100,7 +100,7 @@
end

create_table "solid_queue_scheduled_executions", force: :cascade do |t|
t.integer "job_id", null: false
t.bigint "job_id", null: false
t.string "queue_name", null: false
t.integer "priority", default: 0, null: false
t.datetime "scheduled_at", null: false
Expand Down

2 comments on commit 4667002

@matteeyah
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rosa What's the suggested upgrade path here, now that we don't have migrations anymore?

I don't mind re-creating the background job database, since it's completely transactional for us. But for some it might not be practical or possible, because:

  1. They might have scheduled jobs that they wouldn't like to loose.
    1. This is relatively easily resolvable by dumping the data, re-creating the database, then importing the data
  2. People who use a single database won't be able to re-create the database, they'd need to do this with a migration.

Ideally, in the future, we'd be able to somehow run a rake task that figures out the current schema, diffs that with the schema in the file, then migrates the database to the declared schema.

@rosa
Copy link
Member Author

@rosa rosa commented on 4667002 Sep 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @matteeyah, if we have to change the schema in the future, we'll add a migration. In this case, the schema generated was wrong, previous migrations used bigint, the schema with integer didn't match the migrations, which is why I pushed a change to the schema.

Please sign in to comment.