Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Apply schema filter more selectively#587

Merged
greg0ire merged 2 commits into
doctrine:3.4.xfrom
greg0ire:selective-filter
Jan 27, 2025
Merged

Apply schema filter more selectively#587
greg0ire merged 2 commits into
doctrine:3.4.xfrom
greg0ire:selective-filter

Conversation

@greg0ire
Copy link
Copy Markdown
Member

@greg0ire greg0ire commented Jan 19, 2025

It is more careful, since there seems to be a lot of situations where we do not want to apply the filter.
Let us take the opposite approach and:

  • Have the filter disabled by default, instead of enabled by default.
  • Enable it for precise commands where we know we need it.

This means the ORM is no longer just a dev dependency.

Fixes #584, fixes #585

How can I test this?

composer config repositories.greg0ire vcs https://github.com/greg0ire/DoctrineMigrationsBundle
composer require doctrine/doctrine-migrations-bundle "dev-selective-filter as 3.4.0"

Comment on lines 25 to 33

public function testItDisablesItselfWhenTheCurrentCommandIsAMigrationsCommand(): void
public function testItFiltersOutMigrationMetadataTableWhenRunningSpecificCommands(): void
{
$listener = new SchemaFilterListener('doctrine_migration_versions');
$migrationsCommand = new class extends DoctrineCommand {
$migrationsCommand = new class ($this->createStub(EntityManagerProvider::class)) extends ValidateSchemaCommand {
};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this still a valid test as the opposite for testItFiltersOutMigrationMetadataTableWhenRunningSpecificCommands()?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name is no longer valid, since the filter no longer disables itself (it's disabled by default and stays so until enabled).

There is another test that tests that it's disabled by default.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't about the name but about the 2 cases where we have an instance of UpdateCommand or ValidateSchemaCommand and not having an instance of ValidateSchemaCommand or UpdateCommand. onConsoleCommand is currently only covering one of those cases. UpdateCommand isn't covered either.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed, I think.

@VincentLanglet
Copy link
Copy Markdown
Contributor

This means the ORM is no longer just a dev dependency.

Isn't useless for mongo-odm users ?

Since you're doing only instanceof check, I'm not sure you need to require the package.
Can't we do $foo instanceof SomeClass even if the class doesn't exists ? (We can also add a class_exists check)

The best way to solve this might be to

  • Introduce an interface somewhere
  • Use it in orm bundle (ValidateCommand implements InterfaceFoo)
  • Change the check here (if !$command instanceof InterfaceFoo)

But I didn't found a package used by both orm and migrationBundle. (That would end in the famous doctrine/contract package). Until them I think you can keep the instanceof check without requiring ORM.

@greg0ire
Copy link
Copy Markdown
Member Author

Isn't useless for mongo-odm users ?

You're right, I'll revert this change.

@victor-paumier
Copy link
Copy Markdown

For #584, this solution currently hides the toolbar indicator. If we reactivate it, it still indicates that none of the migrations have been executed
Capture d’écran 2025-01-21 à 15 49 48

On the profiler itself, it corrects the problem well
Capture d’écran 2025-01-21 à 16 03 58

@greg0ire
Copy link
Copy Markdown
Member Author

@victor-paumier I don't understand how that's possible, given that with this solution, the filter will never be enabled in the context of HTTP. Maybe there is a cache you need to clear?

@victor-paumier
Copy link
Copy Markdown

@victor-paumier I don't understand how that's possible, given that with this solution, the filter will never be enabled in the context of HTTP. Maybe there is a cache you need to clear?

I just enable it manually, I just wanted to know if it was the expected result.
So does it means that this PR will deprecate the toolbar block of the template? Or do you plan to fix it later?

@greg0ire
Copy link
Copy Markdown
Member Author

I just enable it manually

You enabled the filter? Why?

There is only one call to it.
@greg0ire greg0ire force-pushed the selective-filter branch 2 times, most recently from 1e8ff6b to 47cfdb3 Compare January 21, 2025 18:09
It is more careful, since there seems to be a lot of situations where we
do not want to apply the filter.
Let us take the opposite approach and:
- Have the filter disabled by default, instead of enabled by default.
- Enable it for precise commands where we know we need it.
@greg0ire
Copy link
Copy Markdown
Member Author

ping @derrabus @SenseException 🙏

Copy link
Copy Markdown
Member

@SenseException SenseException left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't understand the use case of @victor-paumier though. Maybe it can be addressed separately when a deeper explanation is available.

@greg0ire
Copy link
Copy Markdown
Member Author

Me neither, and they don't answer my questions so 🤷

@greg0ire greg0ire merged commit e858ce0 into doctrine:3.4.x Jan 27, 2025
@greg0ire greg0ire added this to the 3.4.1 milestone Jan 27, 2025
vitek-rostislav added a commit to shopsys/shopsys that referenced this pull request Dec 23, 2025
- removed unnecessary conflict as the orginal problem is already resolved
- see #3749
- see doctrine/DoctrineMigrationsBundle#587
ShopsysBot pushed a commit to shopsys/migrations that referenced this pull request Dec 23, 2025
- removed unnecessary conflict as the orginal problem is already resolved
- see shopsys/shopsys#3749
- see doctrine/DoctrineMigrationsBundle#587
ShopsysBot pushed a commit to shopsys/project-base that referenced this pull request Dec 23, 2025
- removed unnecessary conflict as the orginal problem is already resolved
- see shopsys/shopsys#3749
- see doctrine/DoctrineMigrationsBundle#587
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Regression: Migrations table already exists error in 3.4 After v3.4 all migrations shown as not executed in dev toolbar

4 participants