Skip to content

Replace 47 with SFBayChapterId variable #242

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 9, 2025
Merged

Replace 47 with SFBayChapterId variable #242

merged 1 commit into from
Apr 9, 2025

Conversation

alexsapps
Copy link
Collaborator

No description provided.

@alexsapps alexsapps requested a review from jakehobbs April 7, 2025 19:52
Copy link
Member

@jakehobbs jakehobbs left a comment

Choose a reason for hiding this comment

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

def nicer than what we had before, but curious your thoughts on handling this long-term. do you think sf bay will always be a "special case" and/or could we handle this more dynamically?

@@ -189,7 +191,7 @@ select
'',
'',
NULL,
'47',
'` + model.SFBayChapterIdStr + `',
Copy link
Member

Choose a reason for hiding this comment

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

❓ does this not work for this one?

Suggested change
'` + model.SFBayChapterIdStr + `',
model.SFBayChapterIdStr,

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is a list in SQL in the middle of a huge backtick string, not a Golang function call or other list in Go :)

@alexsapps
Copy link
Collaborator Author

def nicer than what we had before, but curious your thoughts on handling this long-term. do you think sf bay will always be a "special case" and/or could we handle this more dynamically?

I think it can make sense to try things out on the main chapter or greater bay area generally before applying them to other chapters. We could have dynamic "chapter settings" thing and add a new setting when we want to experiment on a chapter level, but if it's always just main chapter vs all chapters, then that might not be necessary. We could just wait until it gets annoying and then change it later / make use of it incrementally as needed. I'm not seeing a situation where we would get locked into something that's really hard to change. Perhaps it would be good to have a rule that we don't hard-code more than 3 chapter IDs for one feature -- once we want to add a 4th then we know it's a real thing and we make a chapter settings mechanism for it.

@alexsapps alexsapps merged commit 6fcb83f into main Apr 9, 2025
1 check passed
@alexsapps alexsapps deleted the alex/chapter47 branch April 9, 2025 02:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants