Fixing the expired cart command #14532
Conversation
mamazu
force-pushed
the
fixing_expired_carts
branch
from
cb7e03e
to
2d2aa1d
Compare
|
I was working on it for a while and despite it isn't crashing on the very beginning, the memory seems to leak. Did you try to process ~10k/20k of carts? |
|
Yeah, we haven't run the command in a while and gathered over 1 million carts. The proper solution would be to return a result iterator from doctrine and do it like that. The problem is that this isn't a solution for the Sylius default because this would mean changing the return type of the function. So this duct tape solution must suffice for now. |
|
Just make a new command. 😄 |
|
Iterable isn't working, too. I spent about 1 man day and nothing, after all memory still has been leaking. |
|
Try clearing the entity manager after flushes. |
|
@vvasiloi I really checked everything, that too 😂. |
|
Well that worked for us. |
Or we just take the old command and wire up a different cart remover. But in my opinion we should refactor the command anyways. So that it has a process indicator. Because there is nothing more annoying than having a command with no process indication and only hope that it does something. :D |
|
Has been replaced by #14569 |
The problem
Currently when trying to remove a huge amount of expired carts (like 1 million) the process will crash before it even begins. The issue is that in the current implementation
findCartsNotModifiedSincereturns a list of all carts which kills the memory when trying to execute it.The solution
Run the find command in a batch and then remove the batch. (The problem is I don't really understand phpspec so someone which more experience with that could maybe help out here.)
I am also using the fact that php has a leaky scope, it's not pretty. But this is the only way to not dispatch more than one
SyliusExpiredCartsEvents::POST_REMOVE.Other considerations
It could even be replaced with a direct delete statement?