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

Issue with multiple gii runs from command line #5224

Closed
schmunk42 opened this issue Sep 29, 2014 · 8 comments
Closed

Issue with multiple gii runs from command line #5224

schmunk42 opened this issue Sep 29, 2014 · 8 comments
Labels
ext:gii status:to be verified Needs to be reproduced and validated. type:bug Bug

Comments

@schmunk42
Copy link
Contributor

The Module class from gii rebuilds it's generators property.

On the second run it takes the created object as a configuration, which throws an error:

Exception 'yii\base\InvalidConfigException' with message 'Unsupported configuration type: object'

in /path/to/phundament/vendor/yiisoft/yii2/BaseYii.php:350

Stack trace:
#0 /path/to/phundament/vendor/yiisoft/yii2-gii/Module.php(116): yii\BaseYii::createObject(Object(yii\gii\generators\model\Generator))
#1 /path/to/phundament/vendor/yiisoft/yii2/base/Controller.php(138): yii\gii\Module->beforeAction(Object(yii\gii\console\GenerateAction))
#2 /path/to/phundament/vendor/yiisoft/yii2/console/Controller.php(91): yii\base\Controller->runAction('giiant-model', Array)
#3 /path/to/phundament/vendor/yiisoft/yii2/base/Module.php(462): yii\console\Controller->runAction('giiant-model', Array)
#4 /path/to/phundament/vendor/yiisoft/yii2/console/Application.php(161): yii\base\Module->runAction('gii/giiant-mode...', Array)
#5 /path/to/phundament/vendor/schmunk42/yii2-giiant/commands/BatchController.php(95): yii\console\Application->runAction('gii/giiant-mode...', Array)
#6 [internal function]: schmunk42\giiant\commands\BatchController->actionIndex()
#7 /path/to/phundament/vendor/yiisoft/yii2/base/InlineAction.php(55): call_user_func_array(Array, Array)
#8 /path/to/phundament/vendor/yiisoft/yii2/base/Controller.php(150): yii\base\InlineAction->runWithParams(Array)
#9 /path/to/phundament/vendor/yiisoft/yii2/console/Controller.php(91): yii\base\Controller->runAction('', Array)
#10 /path/to/phundament/vendor/yiisoft/yii2/base/Module.php(462): yii\console\Controller->runAction('', Array)
#11 /path/to/phundament/vendor/yiisoft/yii2/console/Application.php(161): yii\base\Module->runAction('giiant-batch', Array)
#12 /path/to/phundament/vendor/yiisoft/yii2/console/Application.php(137): yii\console\Application->runAction('giiant-batch', Array)
#13 /path/to/phundament/vendor/yiisoft/yii2/base/Application.php(371): yii\console\Application->handleRequest(Object(yii\console\Request))
#14 /path/to/phundament/yii(30): yii\base\Application->run()
#15 {main}

Called like so:

foreach ($tables AS $table){
    [...]
    \Yii::$app->runAction(ltrim($route, '/'), $params);
}

Possible workaround, check if the generator is already an object:

if (isset($this->generators[$id]) && is_object($this->generators[$id])) {
    continue;
}
@samdark samdark added this to the 2.0 GA milestone Sep 29, 2014
@qiangxue
Copy link
Member

Most actions are not designed to support re-entry. You can work around this issue by creating a new instance of application. Will not fix it.

@schmunk42
Copy link
Contributor Author

Do you have any special advices about this approach, because when I create another instance in the console command...

$temp = new \yii\console\Application(['id'=>'foo','basePath'=>'.']);
$temp->run(....);
// The following line fails
\Yii::$app->runAction(ltrim($route, '/'), $params);

Looks like my existing application also gets reconfigured and looses it controllerMap i.e.
I haven't double-checked this completely yet, but creating a temporary console application from a console application should work?

@cebe cebe removed this from the 2.0 GA milestone Sep 30, 2014
@qiangxue
Copy link
Member

Because Yii::$app is a singleton, you should keep a copy of the old application, and then run the command. After that, restore with the old application.

@schmunk42
Copy link
Contributor Author

OK.

Just wanted to note that this looks to quite some overhead to me, but most likely there are side-effects with re-running I don't see at the moment.

PS: It's especially about gii batches, see here for an example to get a more complete picture.

@schmunk42
Copy link
Contributor Author

It turns out that this is more problematic than I thought. I cannot just clone the current application, because the references to the modules are still pointing to the same object.

So I have to look for the appropriate console config files and create a whole new console application instance with all modules and components from scratch.

Is there a nicer way to do this, eg. getting the current console config from the application?

[edit]
Sample code:

            $app  = \Yii::$app;
            $temp = new \yii\console\Application($config);
            $temp->runAction(ltrim($route, '/'), $params);
            unset($temp);
            \Yii::$app = $app;

schmunk42 added a commit to schmunk42/yii2-giiant that referenced this issue Sep 30, 2014
@qiangxue
Copy link
Member

qiangxue commented Oct 1, 2014

Could you try again with the latest code?

@schmunk42
Copy link
Contributor Author

@qiangxue I tried it with the latest code, but I still get the same error.

I was able to try the command line batches with larger schemas and I must say this has a huge(!) impact on performance for Yii2 on the command line.

Creating an $temp application is about 3.5x times slower than using the existing one.
So at least for the Gii Module we should support reentry into actions.

Couldn't we have customGenerators and coreGenerators which get merged and their objects instantiated to generators?

@qiangxue qiangxue added this to the 2.0.1 milestone Oct 10, 2014
@qiangxue qiangxue added the status:to be verified Needs to be reproduced and validated. label Oct 10, 2014
@schmunk42
Copy link
Contributor Author

You can reproduce the problem with the BatchController mentioned before.

I had to introduce this (hopefully) temporary fix, but this created a really non-wanted dependency to the configuration locations.
I just wanted to add this, because the current solution forces me to know the location of the application configuration, which is not necessary with re-entry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ext:gii status:to be verified Needs to be reproduced and validated. type:bug Bug
Projects
None yet
Development

No branches or pull requests

4 participants