Static variables are persisted across migrations, breaking cache logic. Each migrations should be independent, and carry its own PHP request. about migrations HOT 4 CLOSED

Starting a new PHP process for each migration would have a huge performance impact for the execution of migrations, which seems a no-go.

I suggest you to fix that in your project: register a listener for the onMigrationsVersionExecuted or onMigrationsVersionExecuting event (not sure which one of them is best for your case) that would clear your cache between migrations.

from migrations.

@bs-thomas static variables are not request-based. They are process-based.

from migrations.

This is how static variables work. Using a static variable as a cache was a bad call on you side, sorry. For the reasons given by @stof, this bug report is not actionable for us.

from migrations.

Thanks for your quick response. I appreciate it.

I can understand it is a performance impact for doctrine. And I did think about it, and also agree so. So I will try to find an alternative for this.

@derrabus While I appreciate your advice, actually I don't quite understand why it was a bad idea. From my understanding, the use of static variable caching is actually quite a common use-case scenario for request-based caching, especially when PHP was made to be "request independent". Also for my use-case, it was not "object-dependent", so all instances of that same class are going to have the same table columns, so "static" seems to be the way to go. Or did I misunderstand something here?

** I understand this is off-topic already, just a friendly social discussion, just hoping to learn from you a little more :-)

from migrations.