-
Notifications
You must be signed in to change notification settings - Fork 41
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
Throw an exception when the Indexer queue is not cleared #42
base: master
Are you sure you want to change the base?
Conversation
Why not flush the queue on destruct, instead of throwing an exception? |
Yeah that's also possible. I'm open to suggestions 👍 |
Hello you all, I'm not sure requesting a database or throwing an exception in the destructor is a good thing. IMO people should rely on framework triggers to handle it. As this lib is Symfony friendly, we could add an event listener to do something in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼 I like it
You're right. I'm doing this in my current project (which uses another elasticsearch libaray): public function __destruct()
{
if ($this->bulkCount > 0) {
$this->commit();
}
} It mostly (99% of the time) runs fine, but sometimes it throws like this at the end:
So it's probably not a good idea to do this... |
Instead of flushing on |
This is kind of experimental but I had this idea where we can prevent developers from misusing the Indexer.
Upon __destruct, we check the Indexer queue, and if there is Documents here we throw an exception 💥.
My only fear is that:
Is it an issue?
This PR also adds a "clear" method to empty the queue.