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
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 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?
@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 💪
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 runphp 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
While my Aggregation looks like this:
Steps To Reproduce
doctrine/migrations
usingcomposer require doctrine/migrations
php bin/console doctrine:migrations:diff -n
php bin/console doctrine:migrations:migrate -n
php bin/console doctrine:migrations:diff -n
The text was updated successfully, but these errors were encountered: