SubDirectory/SubFolder is being ignored from sourceURL for migration scripts

[jagdishkumbhare]

Is your feature request related to a problem? Please describe. At the moment, all migrations files are required to be in directory ex."file://xyz", subdirectories are ignored. Developer need to add migration files in same folder even if they belong to different release.

Describe the solution you'd like Better way to organize would be to have structure like, migrations/v1 1_xyz.up.json 1_xyz.down.json 2_xyz.up.json 2_xyz.down.json

migrations/v2 3_xyz.up.json 3_xyz.down.json 4_xyz.up.json 4_xyz.down.json

It would better if sourceURL is scanned for subdirectories also. This will not break existing functionality if we use Walk instead of ReadDir in iofs.go.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[dhui]

Do you use VCS to manage migration sources for releases?

Having a hierarchy of migrations will make debugging migrations much harder. e.g. dealing with unexpected deeply nested migrations Using sub directories is confusing since the there are multiple ways to flatten the directory, none of which intuitively align with the existing logic for determining migration order (the file name). Are you suggesting that sub directories be traversed but the path hierarchy is ignored and only the file name be used for migration order?

[jagdishkumbhare]

Yes,We use VCS to manage migrations. I feel having subdirectories will help to organize the code properly, Today after few releases, directory will easily have more than 100 files, and it will be difficult to search files unless we include release number in prefix, Filename prefix is the one which will decide the order, which can be anything sequence or unix timestamp, Today also its developers responsibility to use prefix as unique number, Same way when we have subdirectories, developer will make sure that uniqueness is maintained irrespective of where file present.

[dek4nice]

there are multiple ways to flatten the directory

and any way would be admissible.

I see it can use existing logic for determining migration order if directory naming will follow as:

1_name.up.sql
1_name.down.sql
2_name.dir/
  | 1_name.up.sql
  | 1_name.down.sql
  | 2_name.up.sql
  | 2_name.down.sql
  | 3_name.dir
    | 1_name.up.sql
    | 1_name.down.sql
3_name.dir/
  | 1_name.up.sql
  | 1_name.down.sql
4_name.dir/
  | 1_name.up.sql
  | 1_name.down.sql
  | 2_name.up.sql
  | 2_name.down.sql

In this order each directory operates as one file and it doesnt break "app-scheme-first" rule