Question

My setup is that I have a testing environment which runs via its own database and all tests are seeded as-is-needed on each test run. Therefore it's a clean database and there is no need to worry about updating the migrations data inline with a database.

This seems like the most sane way of doing this but it requires a button click for each time you export in order to update the migration, which of course needs to be always the very latest one anyway.

Is it possible to configure this? If not I think it would be a fairly common use-case so an option to configure this would be welcomed.

Comments

Hello,

Unfortunately, I'm not entirely sure what you're looking for.

If you're asking whether migrations can be defined differently for the test database and the production database, this isn't possible.

However, during development, you can add multiple migrations. Before committing, you can delete all the created migrations and create a new one that consolidates all the changes at once.

---

OK let me try to bring you in the loop.

I develop a framework which is PHP8 savvy. When running tests from command line, I do:

./project.sh testing:run

When this happens, the exported data from Skipper is processed and a database is created and thus seeded.

Unfortunately, the exported data does not include changes made unless you click "Update Revision".

I wish to miss this step out entirely, and one-click the Export button and voila, it updates the revision for me as well as outputting the data.

So the question is: can you (and if not, will you) make updating the revision default behaviour on export?

Answer 1

Ok, I understand now. But this is already included in the Skipper.

When you press export and there is new changes in the migrations, Skipper automatically tell you about this and ask if new migration should be created.

So if you not see this message, you probably turned it off. Check your settings and search for this option

Comments

So yes, this points it out. What I'd want is an option to remember my choice; create a new revision, update the existing revision, or ignore.

---

Sorry, this is not available and is not planned for now.

We believe this message is important to let everyone know that there is a change (intended or unintended) and that they should check to ensure the new migration will be created.

We believe that a single click in this case is better than adding a migration that the user was unaware of, which could break the entire migration system, for example, in production.

---

I'm entirely in testing development mode (as you would expect when using Skipper?) so exporting for the purpose of production seems very alien to me.

---

I completely understand your perspective, and I appreciate your input. As I mentioned, we currently have no plans to implement this feature.

However, if there is increased interest in the future, we will certainly consider how best to incorporate it.

---

I can understand that, feature development is hard even at the planning stage. I didn't expect very much but can only comment on my own personal experience. As a framework developer you are required to think of other developers which is where I was coming from. I don't think the option to "remind" is a bad one, in fact it works well, but encompassing users use-cases to include a "remember my choice" is what I was getting toward.