[8.x] Resolve Blueprint class out of the container #40307
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, it is almost impossible to swap the `Blueprint $table` implementation for migrations with a fake one from within a "package space". Because the `Schema` facade returns a new object each time from the `getFacadeAccessor` method (hence there is no way of mocking or hot swapping) and non of the other objects are resolved out of the container. (Connection objects or Builder objects) There is also no change of using the `resolver` property on the `Builder` class from a package space because if you set it before the migration starts it will be thrown away after the `Schema` is called in the migration. Currently "illuminate/database" depends on "illuminate/container" so we can use the Container class directly. This way it is possible to swap the Blueprint class upon the `registration phase`.
|
Why do you want to write a custom Blueprint? |
|
This is part of the migrator UI package, we need to have a spy blueprint to see what is going to be done in migrations without actually performing them. Currently, the package is reading the migration code by regex, which is crappy. https://github.com/rezaamini-ir/migrator Custom Blueprint can also be used to avoid certain queries in some environments, like avoiding the creation of indexes in test mode. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, it is almost impossible to swap the
Blueprint $tableimplementation for migrations with a fake one from within a "package space".Because the
Schemafacade returns a new object each time from thegetFacadeAccessormethod (hence there is no way of mocking or hot swapping) and non of the other objects are resolved out of the container. (Connection objects or Builder objects)There is also no change of using the
resolverproperty on theBuilderclass from a package space because if you set it before the migration starts it will be thrown away after theSchemais called in the migration.Currently "illuminate/database" depends on "illuminate/container" so we can use the Container class directly. (if not wrong)
This way it is possible to swap the Blueprint class upon the
registration phase.