Conversation
added 2 commits
March 8, 2017 15:01
The underlying column is a string and MySQL's optimizer does much better when comparing strings to strings.
Owner
|
No issues with this patch. I am going to make one super minor improvement with a strtolower() on the input for user friendliness, but that is it. |
Author
|
Good idea. Thanks for the merge! |
Owner
|
Thank you for contributing. I appreciate it! I hate being so busy that I can sometimes barely come around to look at pull requests. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DPL3 doesn't currently have a way to filter revisions relative to the current time (e.g. "get me all revisions in the last hour"). This patch provides one way to implement that feature.
My motivation is that I'd like to build a list of the most recent 10 edits via DPL. This list needs to be regenerated every time it's viewed (allowcachedresults=false) and it will be on our front page, so performance is important. It would technically be possible to use allrevisionsbefore=2017-03-01|count=10 but that will gradually slow down unless the allrevisionsbefore date is updated manually. With this patch, it's possible to create a list of the most recent edits that will always be efficient.
The patch adds the following timestamps: today, last hour, last day, last week, last month, last year. They're converted into numeric timestamps before being passed to the database.
I'm not married to the current format (e.g. allrevisionssince=last day). I toyed around with the syntax and this seems to be the cleanest. It'd also be possible to expose the value passed to DateInterval directly (e.g. allrevisionssince=P1M3D2H for 1 month, 3 days and 2 hours) but that's less friendly and exposes implementation details. Suggestions are welcome.
@Alexia, I've also got an all-fixes branch in my clone which contains all 3 changes (revision filter efficiency, sort direction and this change) if you want to merge everything in one shot. There's a minor (and easily-resolved) merge conflict that you'll run into if you merge them one-by-one.