Ability to automatically run dependent scripts in correct order

[wizofaus]

Is your feature request related to a problem? Please describe.
Currently if I have a SQL script for one view "bar" with the name "dbo.bar.view.sql" that depends on another view "foo" (defined in dbo.foo.view.sql), running the former can fail if the latter doesn't exist yet or have the right columns.
This can also happen between views and functions (both can depend on the column definitions/parameters of the other).

Describe the solution you'd like
If grate could detect ahead of time that view (or function) "bar" or depended on view (or function) "foo" and run the scripts in the order "foo" then "bar", that would be ideal.

Describe alternatives you've considered
The ability to keep running remaining scripts even if there is an error that's caused by a dependency issue, then grate could simply be run multiple times as needed (or even have its own ability to run on repeat until all issues resolved).
I'd also be OK if there were some way to explicitly tell Grate about dependencies between scripts.

Additional context
Scripts are all SQL server T-SQL. I'm not sure if other database engines have the same issue, but I suspect they would.

While dependencies between views can be solved just by renaming the files, it does mean for inconsistent file naming conventions. And the problem of functions that are dependent on views can't be solved like this (and yes, I do have one such case currently - it's a table-valued function that uses a couple of other views to generate the result).

Note that all my VIEW and FUNCTION scripts are CREATE OR ALTER statements.

Stored procedures are actually not a problem, BTW, as SQL server doesn't require that any referenced views/functions/secondary procedures have the expected columns/parameters.

[gmilke]

I am having the same issue but for Tables. The first table has a foreign key constraint on a table that hasn't been created yet. InterestRate depends on RateType table.

I checked what RedGate SQL Compare does with those 2 tables. It puts the lookup table first in the script.

In this context, I am trying to create a blank database on my localhost for Integration testing. I want to drop/create the database each time I run the build set to LOCALHOST. I am currently manually using RedGate SQL Compare to get the db in sync with my source control scripts.

I like these ideas:
Describe alternatives you've considered
The ability to keep running remaining scripts even if there is an error that's caused by a dependency issue.
I'd also be OK if there were some way to explicitly tell Grate about dependencies between scripts.

[wizofaus]

I'm doing all my table modifications via /up scripts, and using a slightly different naming convention there to enforce order, so foreign key constraints haven't been an issue for me so far.

One thing I did just discover that slightly surprised me - it turns out if your stored procedure definitions only refer to tables/views that do already exist, but you try to refer to a column that doesn't exist among them, the CREATE OR ALTER statement will fail.
So can we be certain that /sprocs scripts are always executed after /views scripts? I'm not sure about whether sprocs can depend on /functions syntactically.