You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to reliably and safely use a custom Schema Builder for an existing Connection, you need to create an entirely new thinly wrapped Connection. Furthermore, if you simply override the instance bound to the container it puts the instance resolved from the Schema Facade out of sync with the Schema Builder instance set on the Connection.
The reason this is the case, is that even if you set db.schema there are many places that use getSchemaBuilder() on the connection which ignores whatever is bound to the container. In that getSchemaBuilder() method it returns a hardcoded instance of the framework's Builder class.
I would propose an implementation which is already currently used with schemaGrammar in the Illuminate\Database\Connection class.
class Connection implements ConnectionInterface
{
// ..../** * The schema builder implementation. * * @var \Illuminate\Database\Schema\Builder */protected$schemaBuilder;
/** * Set the schema builder used by the connection. * * @param \Illuminate\Database\Schema\Builder $builder * @return $this */publicfunctionsetSchemaBuilder(SchemaBuilder$builder)
{
$this->schemaBuilder = $builder;
return$this;
}
/** * Get a schema builder instance for the connection. * * @return \Illuminate\Database\Schema\Builder */publicfunctiongetSchemaBuilder()
{
if ($this->schemaBuilder) {
return$this->schemaBuilder;
}
if (is_null($this->schemaGrammar)) {
$this->useDefaultSchemaGrammar();
}
returnnewSchemaBuilder($this);
}
// ....
}
It is not the end of the world to have to wrap the connection, and I doubt there are too many applications/packages that need to override the Schema Builder, so I can understand if this is deemed out-of-scope.
This came to light because our company created plank/snapshots as an approach to versioning content, which relies on a custom Schema Builder and Migrator.
Let me know if this could be supported and I will create a PR to be reviewed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
In order to reliably and safely use a custom Schema Builder for an existing Connection, you need to create an entirely new thinly wrapped Connection. Furthermore, if you simply override the instance bound to the container it puts the instance resolved from the
Schema
Facade out of sync with the Schema Builder instance set on the Connection.The reason this is the case, is that even if you set
db.schema
there are many places that usegetSchemaBuilder()
on the connection which ignores whatever is bound to the container. In thatgetSchemaBuilder()
method it returns a hardcoded instance of the framework'sBuilder
class.I would propose an implementation which is already currently used with
schemaGrammar
in theIlluminate\Database\Connection class
.It is not the end of the world to have to wrap the connection, and I doubt there are too many applications/packages that need to override the Schema Builder, so I can understand if this is deemed out-of-scope.
This came to light because our company created
plank/snapshots
as an approach to versioning content, which relies on a custom Schema Builder and Migrator.Let me know if this could be supported and I will create a PR to be reviewed.
Beta Was this translation helpful? Give feedback.
All reactions