Phinx: Get -e <environment> from phinx.php config

[l0gicgate]

I've been trying to find a way to get the environment option from my phinx.php file and it seems rather complicated.

The only way right now is to export PHINX_ENVIRONMENT prior to running the phinx console and I don't want to have to do that.

Is there a simple way to do this?

[lorenzo]

What's the use case for getting back the environment name?

[l0gicgate]

So I can load the proper .env file which gives my dependencies a PDO to the right DB.

During my migrations I have to stage fixtures in the database, my repositories require a connection to the right database and there's no way for me to know which environment was detected / which one it defaulted to.

I can put a code sample together if you really need to visualize what I'm trying to do.

Thanks

[broberts-mrmc]

Pierre,

I've yet to contribute to the Phinx project (sad face) though I watch and utilize the project, so take this with a grain of salt. My point is, it's NOT an opinion or recommendation from a Phinx project lead or even contributor.

That said, I believe we've done something like this by leveraging our project/application's configuration loader in the Phinx source with one line of code. What we've done is include our application's configuration loader in Phinx's PHP config file, and set the various Phinx "default" database configuration options to items from our configuration loader. That is, our configuration loader, looks at information about its runtime environment (e.g. host/server, path of executing script, etc) to load appropriate DB settings among other things, which are assigned to the appropriate options in the Phinx config. I suppose you could actually instantiate a PDO object too.

Unless I'm misunderstanding, it seems a similar solution would also work in the situation you're describing. Does your app/code base have some kind of configuration loader?

This approach mostly eliminates the need for the Phinx command "-e" option, though we're looking at possibly leveraging it for a different purpose – to support multiple databases, not different instances or environments for/of the same database. However, we're still working out the details on this piece as there would really need to be a district set of migrations for each database, though, in our case, there's only one project to contain them.

Regards,

Ben Roberts

On Jul 22, 2017, at 11:31 AM, Pierre Bérubé <[email protected][e-mail]> wrote:

So I can load the proper .env file which gives my dependencies a PDO to the right DB.

During my migrations I have to stage fixtures in the database, my repositories require a connection to the right database and there's no way for me to know which environment was detected / which one it defaulted to.

I can put a code sample together if you really need to visualize what I'm trying to do.

Thanks

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/cakephp/phinx/issues/1137#issuecomment-317194536, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APvK7DHK6bB03wBvnby8qYMMWKbkb3kzks5sQiPAgaJpZM4Of3Zl.

[l0gicgate]

This is my problem precisely @broberts-mrmc I actually have 3 different databases.

I'm already doing all my dependency wiring via a phinx.php config file. Problem is it cannot detect testing environment. Only detects whether it is running in prod or dev.

Hence why I need to know what the -e flag is prior to providing the PDO to the configuration array. That only becomes available once the console command is executed or if you export PHINX_ENVIRONMENT.

Simple fix would be to set the detected envinronment inside $_ENV once Phinx is aware then it can be accessed from my phinx.php config

[broberts-mrmc]

Will process of elimination not work in this case? In other words, if the run-time environment/instance is not DEV and not PROD, assume it's a local/developer testing environment/instance?

I'm assuming your "DEV" is a non-prod./non-local environment/instance.

[l0gicgate]

@broberts-mrmc the way the detection works is it looks at the directory name on the production instance.

In a production environment we'd have all the src in a /production folder otherwise it'd fall back to staging environment.

On my local dev envinronment I don't have that unfortunately so it just falls back to development env. There's nothing for me to do elimination with unfortunately as you mentioned.

The only thing that would work is for me to get the phinx -e flag really that's the best source of truth in this case.

[broberts-mrmc]

It seems it would be a fairly minor modification (that what the person NOT doing the coding always says) to expand your current pattern/approach by putting the source code in a "/ staging" directory in the staging environment(s) or on the staging server(s), and then tweak the configuration loading logic to "fall back" to a "local" configuration rather than one for staging or dev. Granted, I don't know much about your project. Good luck!

[sinnbeck]

+1 for this. We need to be able to get the environment to load the proper config file as well. (Similar setup as @l0gicgate)
(We are using $_SERVER['argv'][3] currently but would prefer a proper approach)

[Ymx1ZQ]

we have the same problem. the $_SERVER['argv''][3]??'development' workaround is great for now, but a proper solution would be much appreciated!

[l0gicgate]

I might just open a PR to fix this. I think this is rather important and others are having the same issue.

[broberts-mrmc]

@l0gicgate In case you didn't see it, big thanks to the contributors related to #1070. I believe "migrations for multiple databases in a single project" are now possible using two Phinx built-in features (i.e. the "-e" option and the new namespaces with custom paths) plus the minor customization to "bootstrap" your own runtime config/settings.

[l0gicgate]

@broberts-mrmc that still doesn't solve this issue unfortunately.

[broberts-mrmc]

You're right, it doesn't strictly solve the "getting the environment" issue. Sorry, I didn't mean to suggest otherwise.

However, it seems to be the final piece in solving the problem of "performing migrations on multiple databases in a single project" (i.e. being able to store different sets of migration files for different databases) which, depending on the reason for needing to retrieve the environment, might be a solution for some who are looking to retrieve the environment.

[dereuromark]

Indeed, opening a PR for this seems the best option to move forward, it will also make it easier to discuss then.

[l0gicgate]

Closing this issue. Follow discussion in PR #1308.

[l0gicgate]

The referenced PR was a partial fix for this issue. For anyone who wonders how you can obtain the environment from within your phinx.php config file, you can instantiate a symfony ArgvInput instance which mocks the Phinx CLI.

It does feel like a hack, but it works well and if you need any other options from the console you'll be able to access them as well! I'm not sure how we could inject that by default in the configuration in a graceful way. I'm open to suggestion, I'd do another PR if someone has ideas.

Here's the code.

use Symfony\Component\Console\Input\ArgvInput;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputDefinition;
use Symfony\Component\Console\Input\InputOption;

$definitions = new InputDefinition([
    new InputArgument('create', InputArgument::OPTIONAL),
    new InputArgument('migrate', InputArgument::OPTIONAL),
    new InputArgument('rollback', InputArgument::OPTIONAL),
    new InputArgument('test', InputArgument::OPTIONAL),
    new InputArgument('status', InputArgument::OPTIONAL),
    new InputOption('configuration', 'c', InputOption::VALUE_OPTIONAL),
    new InputOption('date', 'd', InputOption::VALUE_OPTIONAL),
    new InputOption('environment', 'e', InputOption::VALUE_OPTIONAL, '', 'development'),
    new InputOption('dry-run', 'x', InputOption::VALUE_OPTIONAL),
    new InputOption('force', 'f', InputOption::VALUE_OPTIONAL),
    new InputOption('parser', 'p', InputOption::VALUE_OPTIONAL),
    new InputOption('target', 't', InputOption::VALUE_OPTIONAL),
]);
$input = new ArgvInput($_SERVER['argv'], $definitions);

$env = $input->getOption('environment');