dbal
dbal copied to clipboard
doctrine
Allow schema_filter to filter any object (index, column, etc)
Feature Request
Would be great if the schema_filter parameter in DBAL allowed filtering of any object including index, column name, etc
| Q | A |
|---|---|
| New Feature | yes |
| RFC | no |
Summary
Current implementation filters only table names (due to debugging in RegexSchemaAssetFilter only tables names are sent there). I think it would be great to filter all objects. This will allow to create manually any object and filter them from doctrine:migrations:diff command in symfony's doctrine migration bundle
Besides consistency across all types of schema objects, what would be the benefit of implementing it?
I fail to see how the functionality of filtering schema objects belongs to a database abstraction layer in the first place. Having some tables managed by the DBAL and some not is the application-level concern, so the application should address it.
The benefit will be from ability to skip any object in schema. I haven’t found any other public interface to be able to extend dbal for implementing such a feature. I think the best will be to provide some kind of interface to pass a callback for skipping objects or any other logic.
The benefit will be from ability to skip any object in schema.
Why do you need that? What problem would it solve?
The benefit will be from ability to skip any object in schema.
Why do you need that? What problem would it solve?
For example I will be able to skip manually created indexes from diff which can not be created using standard doctrine notation. Like GIN index in postgres.
Instead of introducing an API that would allow working around its own bugs, I'd rather have those bugs fixed. At a high level, the DBAL should not try to interpret or modify the database objects that it doesn't understand. See https://github.com/doctrine/dbal/issues/5306#issuecomment-1055644052.
I’m not telling about modifying objects. I’m telling about skipping those object to make it easy to extend the possibilities of database. Even manually. Currently each manual interaction with db requires deleting rows from each new migration which causes a lot of unneeded work
I also had to create a few indexes through postgres directly because they were quite complex and not related to entities. Still they are on tables that Doctrine manages, which has the effect of creating "drop index" in every migration diff I do. I had to create a test to check if I had not forgotten to remove this line in every migration. Being able to exclude some indexes from the analysis would be quite useful.
@Einenlum I'd be happy to review a PR that fixes this problem, if you want to work on this topic.
I have a similar issue as @Einenlum where I need a lower case unique constraint on a table in postgres. The recommendation is to add a custom index in a migration but then the schema manager always tries to remove it.
At a high level, it looks like https://github.com/doctrine/dbal/blob/3.6.x/src/Schema/AbstractSchemaManager.php#L277 needs to use the connection's asset filter the same way listing the tables does https://github.com/doctrine/dbal/blob/3.6.x/src/Schema/AbstractSchemaManager.php#L342. If that seems like a reasonable direction I can create a PR for filtering for indexes. Should I include other assets like columns as that was originally part of the issue?
As an alternative solution would you be open to a PR where the concept of a "CustomIndex" was introduced. A CustomIndex could be applied to a table like any other index, but the schema manager would only check for its existence to determine an add/remove diff. This allows the entity to have documentation of this index that has features that aren't supported by doctrine.
#[ORM\CustomIndex(name: 'unique_names', definition: 'CREATE UNIQUE INDEX unique_names on person (LOWER(first_name), LOWER(last_name))')]
class Person
{
....
}
The definition could be used on create but any subsequent changes other than removal would be ignored.
