Organization HABTM Workshops

[dalmaboros]

• This work is part of Organization Associations #172

What is the goal of this PR and why is this important?

We created the Organization model, and Organizations have and belong to many Workshops. This PR implements that association.

How did you approach the change?

Just made a join table.

Anything else to add?

⚠️ Note: In order for this change to work, the ids on Organization and Facilitator had to be changed from bigint to integer.

[cflipse]

Question: Why is this changing the id column type from bigint to integer ?

If we're going to juggle ID column types ... that probably should happen in it's own PR, with a justification that's going to be findable looking through history on it's own (since everything is a squash, standalone ideas get buried in much larger changesets, which makes history spelunking harder)

[maebeale]

Why was this controller deleted?

[dalmaboros]

It's an empty controller not serving any purpose, so I actually never meant to include it in the initial PR, and thought we could add it back in if we need it in the future.

[maebeale]

We don't want the organizations controller anymore?

[dalmaboros]

I didn't mean to include an empty controller in the last PR, so my thinking was that I'd remove it until we actually need it.

[dalmaboros]

Question: Why is this changing the id column type from bigint to integer ?

If we're going to juggle ID column types ... that probably should happen in it's own PR, with a justification that's going to be findable looking through history on it's own (since everything is a squash, standalone ideas get buried in much larger changesets, which makes history spelunking harder)

@cflipse We can't have foreign key constraints with mixed types, so in order for the OrganizationWorkshops join table to use foreign key constraints, I had to change one of the id types, and it was just simpler to change Organization id to integer than Workshop id to bigint (since Workshop has a bunch of other associations that would then have to change too).

But actually... ideally I suspect we'd rather want all the resources to have id types of bigint, since that's the modern Rails 8 way (and why Organization was generated with id type of bigint in the first place). That would take more work, as Workshop has more existing associations. So, yeah, we could def do a separate PR where we update some (or all?) id types to bigint.

What do you think? Thanks for calling this out, btw.

[dalmaboros]

@maebeale Oops, didn't mean to request another review since I didn't change anything. I did respond to comments tho.

[maebeale]

Looks great, @dalmaboros ! Please rebase main and merge whenever you're ready.

[cflipse]

Question: Why is this changing the id column type from bigint to integer ?
If we're going to juggle ID column types ... that probably should happen in it's own PR, with a justification that's going to be findable looking through history on it's own (since everything is a squash, standalone ideas get buried in much larger changesets, which makes history spelunking harder)

@cflipse We can't have foreign key constraints with mixed types, so in order for the OrganizationWorkshops join table to use foreign key constraints, I had to change one of the id types, and it was just simpler to change Organization id to integer than Workshop id to bigint (since Workshop has a bunch of other associations that would then have to change too).

But actually... ideally I suspect we'd rather want all the resources to have id types of bigint, since that's the modern Rails 8 way (and why Organization was generated with id type of bigint in the first place). That would take more work, as Workshop has more existing associations. So, yeah, we could def do a separate PR where we update some (or all?) id types to bigint.

What do you think? Thanks for calling this out, btw.

Okay, yeah -- that makes sense, as for the reasoning for the change. Ah, foreign keys.

Rails has been using bigint by default since ... 5.x it seems. Which certainly suggests the tables that still have integer ids are going to be the older, more foundational tables.

I'd say that it's very likely that we want to have a single PR dedicated to migrating all ID columns to bigint, one big sweep.

🤔 If you skip adding the FK constraint, that should avoid your need to change the existing tables, to unblock here. Then we can do a follow-up to tighten up the in-db constraints after keys are consistent. How does that sound?