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

[Bug] Aggregation will constantly show up in new Doctrine Migrations #361

Open
keichinger opened this issue Jun 29, 2021 · 3 comments
Open

Comments

@keichinger
Copy link

keichinger commented Jun 29, 2021

  • Symfony version: 5.3
  • Algolia Search Bundle version: 5.1.0
  • Algolia Client Version: 3.0.2
  • Language Version: PHP 7.4

Description

I could reproduce this issue in multiple projects now.

Creating a new Aggregation strictly following the tutorial at https://www.algolia.com/doc/framework-integration/symfony/advanced-use-cases/multiple-models-in-one-index/?client=php will work like a charm.

However, the only thing now is that when you're using doctrine/migrations v3.1.4 (and possibly older versions too - I couldn't test that yet) will cause that when you run php bin/console doctrine:migrations:diff -n that it'll create a new migration with the same SQL every single time.

The SQL in question is

        $this->addSql('ALTER TABLE aggregation_table_name CHANGE object_id object_id VARCHAR(255) NOT NULL');

While my Aggregation looks like this:

/**
 * @ORM\Entity()
 */
class EntityAEntityBAggregation extends Aggregator implements AlgoliaIndexedEntity
{
    public function getEntity () : AdvisorEntry
    {
        /** @var EntityA|EntityB $entity */
        $entity = $this->entity;

        return $entity;
    }


    /**
     * @inheritdoc
     */
    public static function getEntities () : array
    {
        return [
            EntityA::class,
            EntityB::class,
        ];
    }


    /**
     * @inheritdoc
     */
    public function getId () : ?int
    {
        /** @var AlgoliaIndexedEntity $entity */
        $entity = $this->entity;

        return $entity->getId();
    }


    /**
     * @inheritdoc
     */
    public function isIndexed () : bool
    {
        /** @var AlgoliaIndexedEntity $entity */
        $entity = $this->entity;

        return $entity->isIndexed();
    }
}

Steps To Reproduce

  • Create a new aggregation using the tutorial at https://www.algolia.com/doc/framework-integration/symfony/advanced-use-cases/multiple-models-in-one-index/?client=php
  • Install doctrine/migrations using composer require doctrine/migrations
  • Create your first migration using php bin/console doctrine:migrations:diff -n
  • Execute your first migration using php bin/console doctrine:migrations:migrate -n
  • Try re-creating a migration without making any changes to your entities using php bin/console doctrine:migrations:diff -n
  • Find your new migration with an update only to your aggregation's id field, which applies exactly the same changes as in your previous migration.
@keichinger
Copy link
Author

While we're already at discussing „interesting” Aggregation side effects: I'm really wondering whether we really need to declare an Aggregation as an @ORM\Entity()?

Is this an easy way out to better integrate into the existing infrastructure with Doctrine listeners etc.?

The reason I'm asking: IMO the generated table is useless as it just contains a single table and is generally just empty. There is no reason in why this table should exist in the first place.

If possible, it'd be suuuuper nice if we could define our Aggregation just as a regular class and still have the entire Aggregation functionality for free. So, if we could get rid off the generated table/entity, then we'll also fix the migrations side effect at the same time :D

Is this feasible or even possible with the current infrastructure? Or am I missing a major point of why the (or rather, my) empty tables are needed and useful?

WDYT?

@wlasnapl
Copy link

@keichinger you can add in doctrine configuration:
doctrine.dbal.schema_filter: '/^(?!aggregator_table).*$/'

@keichinger
Copy link
Author

@wlasnapl sounds like a great workaround for now! Haven't thought about the possibility to simply ignore/filter the table. Thanks for that!

Obviously, in a perfect world, we wouldn't even need to configure Doctrine to need something like this :) But for now, that's something we can work with 💪

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants