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

Database Groups in Migrations #2087

Closed
TIWDev opened this issue Jul 4, 2019 · 5 comments
Closed

Database Groups in Migrations #2087

TIWDev opened this issue Jul 4, 2019 · 5 comments

Comments

@TIWDev
Copy link

TIWDev commented Jul 4, 2019

The use of protected $DBGroup = 'database-group' in a migration definition; does not appear to be working.

I have two groups set up. Migrations use the default group fine, but one out of seven ligations are specified to use the alternative group, it seems to ignore and run the migration on the default group. Have double-checked everything and the code appears correct.

Have changed the name of the default group to the second database group and specified one out of seven to use the original group, and the migrations are all run on the second group, so database connection settings for both are correct. Migrations table in the database also shows all migrations run under the same group.

Im running the migration using php spark migrate:latest from the command line on MacOS Terminal, using a base install of CI4-Beta 3.

@TIWDev
Copy link
Author

TIWDev commented Jul 5, 2019

Just to update this, it appears to just be the use of database groups within migrations that has an issue. Once the SQL has been executed and the tables created, directing the codebase to use a specific Database Group works fine.

@jim-parry jim-parry added this to the 4.0.0-rc.2 milestone Sep 8, 2019
@MGatner
Copy link
Member

MGatner commented Sep 14, 2019

Wow I'll be honest, I didn't know that property of a migration existed. :) @lonnieezell I don't recall this being a part of MigrationRunner prior to the refactor, and if it was I probably wrote it out. Was this intended to be a filter (i.e. "only gather migrations that have unspecified or matching DBGroup) or an on-the-fly group change (i.e. "gather all migrations but run this one against an alternate group instead").

@lonnieezell
Copy link
Member

I had almost forgotten about that feature honestly :)

It's not really a filter, no. It just says which database connection the migration should use. Can be specified as either a cli argument or in the migration class itself.

@jim-parry jim-parry modified the milestones: 4.0.0-rc.2, 4.0.0-rc.3 Sep 24, 2019
@michalsn
Copy link
Member

michalsn commented Oct 1, 2019

So how this should work actually? We have 3 options now:

  1. default connection
  2. specifying a group via CLI
  3. specifying a group inside the migration class

Setting a group via CLI should override a group from the migration class or not?

I am trying to determine what should have the highest priority here.

@lonnieezell
Copy link
Member

Maybe this should be a bit like a filter in some ways. Part of me wants to simplify and rip it all out, but I suppose it's actually a good feature for more complex setups, since you might want certain things stored on one server, while other things are stored on a different server? My setups don't normally get that complex so unsure lol.

My thinking is it goes like this:

  • A migration that has a group specified will always use that group when doing it's migrations
  • If no group is specified it uses the default group
  • If a group is specified on the cli, then it acts like a filter and only migrations that use that db group are ran. Only applies to up since rollbacks simply rollback the last set of migrations that were ran, no matter how they were filtered.

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

5 participants