-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
feat: Use file cache query builder for searching for favorites #39303
Conversation
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.
The favorites logic in processFilterRulesForFileIDs()
should be removed, also.
All the comments are no-brainers and I understand due to the fact this being an early draft. The approach is fine!
@@ -295,8 +295,8 @@ public function searchByMime($mimetype) { | |||
* @param string $userId owner of the tags | |||
* @return Node[] | |||
*/ | |||
public function searchByTag($tag, $userId) { | |||
$query = $this->queryFromOperator(new SearchComparison(ISearchComparison::COMPARE_EQUAL, 'tagname', $tag), $userId); | |||
public function searchByTag($tag, $userId, int $limit = 0, int $offset = 0) { |
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 suppose the interface needs to be extended as well? Though I don't see a psalm warning.
LazyFolder should look the same, alone for consistency.
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.
Adjusted, would need another adjustment in groupfolders again once merged.
For potential backports this is a bit more tricky but we may just use an ugly direct call on the private class implementation of a separate method then to avoid the interface adjustment.
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.
The foundational PRs were also backported and there the Folder
changes were indeed made private. Since the signature is different, it's likely taking more to make at least tooling accept that state.
d438f85
to
2ea465b
Compare
674aa3c
to
f075ff3
Compare
Ready for review now |
@@ -150,7 +150,7 @@ public function searchByMime($mimetype) { | |||
throw new NotFoundException(); | |||
} | |||
|
|||
public function searchByTag($tag, $userId) { | |||
public function searchByTag($tag, $userId, int $limit = 0, int $offset = 0) { |
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.
That class is a good finding, i shall add searchBySystemTag here also – will be a separate PR.
} | ||
|
||
if ($this->hasFilterFavorites($filterRules)) { | ||
$tmpNodes = $this->userFolder->searchByTag(ITags::TAG_FAVORITE, $this->userSession->getUser()->getUID(), $limit ?? 0, $offset ?? 0); |
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.
Isn't this this thing again where we slice multiple times and then intersect the results? Does this give proper results? I forgot.
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.
limit = 3
offset = 2
a = [0,3,6,9,12,15,18,21,24]
b = [0,2,4,6,8,10,12,14,16,18,20,22,24]
slice(a) // 6,9,12
slice(b) // 4,6,8
intersect(slice(a), slice(b)) // 6
intersect(a,b) // 0,6,12,18,24
slice(intersect(a,b)) // 12,18,24
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.
So, it can give too little results. Sometimes even none when some would be expected.
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.
Good point, will see what could be done about that
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.
Since both the searchBySystemTag
and searchByTag
end up doing a search
with their specific search queries anyway. You can instead build a single search query that performs all the filtering in one go.
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.
and you can probably also include the filtering for the fileids from processFilterRulesForFileIDs
in the same query to remove the need for the findNodesByFileIds
later down
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.
You can instead build a single search query that performs all the filtering in one go.
Search stuff is not in OCP, though. Would be awesome if it was.
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.
using it in the dav app is fine since it's releases are coupled with core
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
f075ff3
to
dfd21de
Compare
When trying to REPORT files that are favorites we still used the old code path to aggregate them, this moves this over to the filecache search query builder methods.
Request to trigger:
TODO
Checklist