Better dev

[jason-raitz]

• updated readme with docker dev instructions
• added a backup of the db to load on dev
  (there are some permissible errors when loading the data)

[jason-raitz]

@anarchivist @danschmidt5189

For a better development experience when working with Galc-ui, I've added in a dump from prod. Below is the ERD for the DB. There is no user data in the dump. quick list of tabes: closures, schema_migrations, ar_internal_metadata, images, items, facets, terms, items_terms. Is this okay?

[danschmidt5189]

I like the idea of providing bootstrapping / seed data. My concern is that we ought to be using Rails seeds for this rather than a DB dump, because:

1. Dumps can interfere with the developer experience around Rails migrations / seeding.
2. Dumps add additional out-of-band maintenance overhead.
3. There's not enough data to warrant using a dump for performance reasons.

So tl;dr I think we're better off using seeds here, either by converting the running database to seeds using a gem like seed_dump or creating synthetic data with ActiveRecord and a gem like faker.

[dmolesUC]

FWIW, because they were also used to import/convert data from old GALC, the existing database migrations also provide a fully populated database (as of its December 2022 state, which of course doesn't include current Terms or more recently added Items). Not very performant, and maybe not the best design decision I could have made at the time, I admit. Generating seeds.rb does seem like the more Rails-y, least-surprise way to do it.

[anarchivist]

agreed with the seeds comments here, so let's go that direction. 🌱

[jason-raitz]

@dmolesUC You were right. The way I was running the db setup wasn't loading in the migration data. For now, I'll remove the sql dump and change the readme to reflect a better dev workflow.