No need to use branding for config files

[dhh]

Drop the Solid. Just Cache. It's cleaner.

[shettytejas]

@dhh, while the recent changes related to handling multiple databases in Rails are welcome, I have a few concerns and suggestions that I think might be worth considering:

Migration Path for Existing Apps: For apps already using a single database setup, transitioning to the new multi-database approach may pose some challenges. While apps with existing databases will continue to work, the "Rails way" moving forward will involve using a separate cache database. For users migrating from a single database to this new setup, what's the recommended approach? Their current schema would still contain the legacy solid_cache tables, which would now need to be removed or moved. Guidance on handling this migration path would be helpful.

Naming and Organization of Schema Files: The introduction of cache_schema.rb as a separate schema file for the cache database seems like an improvement. However, it also introduces a naming inconsistency, as the primary schema remains schema.rb. This could have been an opportunity to better organize schema files by placing them within a dedicated db/schema directory, using names that match their respective databases, such as db/schema/cache.rb and db/schema/primary.rb. This would make it clearer which schema file corresponds to which database. In a single-database setup, the schema file would still be db/schema.rb.

Managing Migrations for Multiple Databases: The new approach also raises concerns about handling future upgrades and migrations. Will updates for new tables in the cache database be handled through traditional migrations? If so, these migrations currently reside in the same db/migrate directory as the primary database migrations. This could lead to confusion when running db:migrate unless explicitly targeted for a specific database. A potential solution would be to introduce separate directories, like db/migrate/cache for all cache database-specific migrations and db/migrate/primary for primary database-specific migrations. This separation would make it clear which migrations belong to which database. In a single-database setup, the migrations would still reside in db/migrate.

I believe these changes would provide better clarity and organization, especially when I see SolidQueue getting the same treatment! What do you think?

[djmb]

Handled by #222