Migration for foorm library model

[bencodeorg]

Creates a Library model for foorm, representing a collection of LibraryQuestions. This entity should make it easier to reason about saving changes to library questions, which will require saving the entire library to which the question belongs. See #38682 for an immediate follow-up putting this to initial use.

Testing

I executed the migration locally via bundle exec rake db:migrate.

Reviewer Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[cforkish]

LGTM! one question about 'published', but no blockers.

[cforkish]

curious about using true as the default here. i would expect libraries to start out unpuplished, no? imo might make more sense to set this to true during seeding so that once we support creating new libraries (if that's ever going to be a thing), new libraries will start out unpubplished. but maybe i don't have proper context on this.

[molly-moen]

I can give context on this. When we started adding the publish option for forms/library questions I set the default to true because none of the forms had a pre-set published state yet, and we aren't using the published state currently. I think it could be worth changing the default in the future when we have a more formalized use of published.

[bencodeorg]

I think that's a good call -- looks like the seeding logic defaults to true, so we're already doing what you suggested :). I think I'll just skip having a db-level default, and rely on places where we save libraries (currently, only during seeding) to decide whether it should be default published or not.

[bencodeorg]

@molly-moen do you think it's reasonable to not have a DB-level default since the seeding logic sets published to true if it's missing?

[molly-moen]

my concern was that is while we will almost always create libraries by seeding, I didn't want us to get into a case where the published state was nil if for some reason that process changes. It is an edge case though, and not a major issue if it does end up nil, so I will leave it up to you.

[molly-moen]

Looks good! I wonder if we should add a column to library questions for library id. We are referencing everything by name and version (and we do queries on library questions by name and version), but for rails-y queries it might make things easier to also have id? I don't have a strongly held opinion on this but am throwing it out there :)

[bencodeorg]

Looks good! I wonder if we should add a column to library questions for library id. We are referencing everything by name and version (and we do queries on library questions by name and version), but for rails-y queries it might make things easier to also have id? I don't have a strongly held opinion on this but am throwing it out there :)

Yeah good point...it does make stuff like this more verbose. I think I'll leave as-is for now but can revisit if we'd like later.

[davidsbailey]

Hey @bencodeorg , I am seeing some diffs after running this migration:

It appears to be because there were no updates to schema.rb or foorm/library.rb in your last commit. Would you be willing to take a crack at fixing this?

[bencodeorg]

Hey @bencodeorg , I am seeing some diffs after running this migration:

It appears to be because there were no updates to schema.rb or foorm/library.rb in your last commit. Would you be willing to take a crack at fixing this?

Ugh I always mess something up with migrations. Will fix, thanks for the heads up!