Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add config item for recursive migration directories #43

Open
kael-shipman opened this issue Jun 17, 2018 · 6 comments
Open

Add config item for recursive migration directories #43

kael-shipman opened this issue Jun 17, 2018 · 6 comments

Comments

@kael-shipman
Copy link
Contributor

Sorry to hammer you with change requests :P. I just thought that allowing recursion in migration directories would make a practical implementation of different migration environments easier. For example:

db/
├── backups/
├── init.sql
└── migrations
    ├── schema/
    │   ├── 1485643154-create_my_cool_table.sql
    │   ├── 1485648520-create_other_cool_table.sql
    │   └── 1485648600-alter_indices.sql
    ├── dev/
    │   ├── 1485643200-add_dev_fixtures_to_cool_table.sql
    │   ├── 1485648700-add_other_dev_fixtures_to_other_cool_table.sql
    │   └── schema > ../schema
    └── prod/
        ├── 1485648700-add_important_production_data.sql
        └── schema > ../schema

With this setup, you can see that as you create schema modifications in schema, they're automatically included in both of the environment folders, dev and prod, while these respective folders can add migrations of their own. However, this only works if the find_migrations command relaxes its max-depth parameter.

@mbucc
Copy link
Owner

mbucc commented Jun 17, 2018

I like it. :) This works nicely with your local config file patch.

The only concern I can think of is if some user has non-migration SQL under a migration directory. I think that is unlikely, so go for it. It looks like Posix find has -depth but not -maxdepth so that's a win.

My general concerns are backwards compatibility, trying to avoid config option explosion, continuing to remove bash-specific commands, and not breaking it.

@kael-shipman
Copy link
Contributor Author

kael-shipman commented Jun 26, 2018

Note: While the above commit works when versions are exclusively timestamps, it doesn't work when versions may match [0-9_.-], as in https://github.com/cfxmarkets/shmig/tree/human-timestamps.

The fix for this is simple: Instead of using -k+2n in the sort command in pending_migrations, use -k+2d (or -k+2V). This changes sorting from numeric (n) to dictionary order (d) or "version" order (V).

(See complete merges at https://github.com/cfxmarkets/shmig/tree/cfx)

@srghma
Copy link
Contributor

srghma commented Jan 7, 2019

+1 for adding -R option to relax max-depth parameter in find_migrations

@kael-shipman
Copy link
Contributor Author

@srghma , I'm not sure what the status of PR #44 is, but what I understood from that discussion is what @mbucc had started to integrate the changes, but never did. I'm now maintaining a stable fork with this functionality at https://github.com/cfxmarkets/shmig if you'd like to use that. Documentation should be up to date on that.

@srghma
Copy link
Contributor

srghma commented Jan 7, 2019

@kael-shipman tnx, will check it

@mbucc
Copy link
Owner

mbucc commented Jan 8, 2019

I agree this is a good feature. The TODO list is:

  • no new arguments---this should be the default behavior.
  • I want to move towards Posix compliance, not away
  • I'm want to verify find ordering of files across all the different types of shells (bash, sh, ash, fish etc) and need some tests in place before I release such a feature.

So it will come, but only when I'm confident it is properly tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants