Closed mattpowell closed 3 months ago
I think your use case makes sense, and we can implement it as a feature. I --might-- not consider implementing it if it added significant complexity to the CLI, but this is really a matter of just adding a for loop.
It might even make sense to support globs in the future.
Hopefully should be able to get to it soon!
Implemented! 🎉
My previous response wasn't a critique of your idea by the way! I realize it kind of read like that. It's a good idea! It's more just commenting on the general philosophy of reducing scope of the library to minimize the amount of code that needs to be maintained.
Is it possible, and if not, is there any interest in allowing the CLI to support multiple
--schema-dir
flags?For example:
This would take all of the .sql files in ./sql/init/ and all of the .sql files in ./sql/feature/commenting/ and read them in to one
DDLSchemaSource
(and then continue to generate a diff/plan as currently implemented).Obviously with this example we could just use a single
--schema-dir
flag and pass the top-level ./sql/ directory to it; however, my usecase is twofold: 1) The ./sql/features/ directory has hundreds of subdirectories (with hundreds of .sql files) and our tooling allows us to know which subdirectory needs to have its .sql files diffed and applied which would improve overall performance (and minimize potential errors with unrelated .sql files) 2) When building our base postgres docker image (which is based off of supabase/postgres) for QA/perf testing, we need to point to their initial set of .sql files and our main ./sql/ directory. Since there is no shared, top-level directory then we need to copy one of the directories over during the build. Having support for multiple--schema-dir
flags would simplify this process.If there's interest in supporting this, then I'm happy to take a crack at sending a PR; however, I have very limited Go experience and I'm more than fine if someone else wants to jump on this :)