Generating dsl introspects the database which may contain columns from other branches.

[thomasdziedzic-census]

Scenario:

1. work on branch A, add a column c to table t through a rails migration.
2. create a new branch off main to do a quick fix which doesn't add any columns, run tapioca dsl to generate dsl rbis.
3. RAILS_ENV=development bin/tapioca dsl --verify fails in CI because in step 2, the tapioca dsl command introspected the database that had columns left over from branch A.

Any ideas on how to handle this cleanly so that step 2 doesn't generate a DSL polluted from branch A's db migration? I was thinking maybe introspecting the schema.rb file or maybe generate a fresh database and generate the dsl from that fresh database rather than using what's in the current development branch.

[sambostock]

I think Tapioca is in the right here.

Active Record's source of truth is not schema.rb, but what the database contains. If the local database contains a column from another branch, as far as Active Record is concerned, that column does exist (unless it's explicitly ignored or something). To make Tapioca ignore it would be to make it generate RBIs that disagree with what methods Active Record would respond to.

I think it would be the responsibility of a tool other than Tapioca to flag that the database doesn't match, but that can differ by application. For example, some applications (like the Shopify monolith) have a structure.sql file that lags behind the actual structure of the database, and which is periodically "rolled up" to reflect the latest state.