-
Notifications
You must be signed in to change notification settings - Fork 235
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
Support for filtering jobs #23
Comments
Great idea. Sadly, redis does not support value searches but we could hand the entire job set over to the client in the form of a clusterize table which can support hundreds of thousands of rows without a performance hit. A form could then be constructed to perform the filtering and update results in the table. It would need a lot of testing. If a client-side solution doesn't work, the server would need to create an internal database that syncs with redis and could be queried via ajax. We could also keep and improve pagination this way. |
Some of our queues are 3GB, so sending all that data to the client for filtering won't work. Why not have the server just read each job from redis, perform the filter, and then stream results to the client? |
@bradvogel ok, 3GB is a great example to think about. It's worth testing at least but I doubt we could have such functionality as an autocomplete. I guess we'd need a syncd database loaded with indexes to achieve that. |
Nah - it'd have to stream each job (key) from redis and run the filter in the backend, then stream it to the frontend if it matches. |
@bradvogel ah! I hear you. Yeah I'm picturing loading indicator, progress bar, options to filter by job data by values & response content. Could be a great addition. |
Note, the intent of this feature request is to only provide basic filtering capabilities when looking at a queue in a particular state, although it would be nice to think on solving that problem in a way that it may open new features as the ones that @krazyjakee is suggesting. But I think it'd be better to solve a small problem at a time. I'm thinking that a solution for this that is efficient for very large queues is to use Pagination can become tricky though because we can't know how many pages a particular search has without doing a full scan which is expensive. I'm thinking that we can replace pagination with a cursor hash that represents the filter and the redis |
Hello! Is there still a feature ongoing for this issue? :) Thanks for the good work :) |
Any news on this issue? |
ping |
While I understand that this ticket has a lot of interest, please refrain from simply bumping - it's not a priority for us, and we don't really have resources to fully support this project. I'm locking and restricting to collaborators. The best way to get progress on this ticket would be to submit a pull request! Linked it to this ticket :) |
It would be nice to filter jobs in a particular state given some criteria. The most useful use case in my opinion is searching for failed jobs whose first error matches some search term.
The text was updated successfully, but these errors were encountered: