Repository navigation
Use the search bar to search for files by tag #326
Description
Activity
- changed the title
[-]Use the search bar to search for files by tag[/-][+]Feature Request: Use the search bar to search for files by tag[/+]on Jul 6, 2016 It makes sense to list files that the user has specifically chosen to associate with the searchphrase, even more highly than if the word just appears in the content / filename somewhere.
I second that we should list these files when a user types in the tag name, preferably above other listings.
I would also love to see the ability to limit search results just to files tagged with a syntax like in GitHub, eg: tag:holiday2016
Reacted by aparatext- changed the title
[-]Feature Request: Use the search bar to search for files by tag[/-][+]Use the search bar to search for files by tag[/+]on Jul 7, 2016 Yeah, actually the full »Tags« functionality in the sidebar is nothing other than a search. We should combine that part with the actual search to make it more useful.
Reacted by Bugsbane, Vinay Sastry, Marcus Döllerer, Reto Gmür, Casey Howard, doomi and Dominik Münsterer@jakobsack Indeed! When you have terrabytes of data, the search functionality becomes critical. What are we using to power the search? Is it the Zend_Search engine?
From memory, I think I recall it being Lucene...
Hmmm ... doesn't look like it from the code. Although there's a very good chance I may be wrong :)
edit
There is a "Search Lucene" app in the owncloud appstore, but that's apparently only supports OC up to version 8.2. The limitation is that it only indexes files "per user" and not globally https://github.com/owncloud/search_lucene/issues/10The question is; is this the path we will look to go down or develop a more "enterprise" global search function here?
You're probably not wrong. I'm remembering this from a long time ago (like OC 5 or something)
It also needs to be faster. If people really use tags, then it's not unreasonable to expect this for 3 minutes:
Followed by a 5 minute hang when you type a letter....
That's after aggressive caching and adding indexes to the systemtag and systemtag_object_mapping tabled.
I don't even think that's unreasonable, really. The issue isn't with the database queries. Those are almost instantaneous with my setup, but the webui still grinds to a halt trying to deal with it.From DataGrip:
sql> Select fileid, filecache.name from filecache inner join systemtag_object_mapping on fileid = objectid inner join systemtag on systemtagid = id where systemtag.name = 'girls_frontline' [2019-06-19 02:07:50] 1415 rows retrieved starting from 1 in 52 ms (execution: 7 ms, fetching: 45 ms)Assuming we kept the ID of the systemtag when we select it in the list, then we can cut out a join and act on
systemtag_object_mapping.systemtagidsql> Select fileid, filecache.name from filecache inner join systemtag_object_mapping on fileid = objectid where systemtagid = 5500 [2019-06-19 02:11:00] 1415 rows retrieved starting from 1 in 44 ms (execution: 7 ms, fetching: 37 ms)Even faster, and that counts time that DataGrip uses to process and render the results. Faster still if I didn't include the
filecache.namefor readability and validation of the results. Each item could be looked up separately in lazy loading by fileid.
When I limit it to 50 result batches (the id is an asc index, so it'll order itself), it's ridiculously fast.sql> Select fileid from filecache inner join systemtag_object_mapping on fileid = objectid where systemtagid = 5500 limit 50 [2019-06-19 02:15:57] 50 rows retrieved starting from 1 in 11 ms (execution: 5 ms, fetching: 6 ms)EDIT: I realize after the fact that I forgot
objecttype = 'files' and, but it yielded very similar numbers, within the error of margin on other system tasks. objecttype is indexed, too, after all.Reacted by Dominik Münsterer@da3dsoul thanks for the intense research! It is a different issue though, as this is about enhancing the search field to include tags.
Since your comment is about improving the performance, could you open a separate issue for that? Thanks! :)
Reacted by Dominik Münsterer14 remaining items
- added a commit that references this issue
on Apr 29, 2021 - added 2 commits that reference this issue
on Jun 22, 2021 - added a commit that references this issue
on Sep 13, 2021 It's been 6 years and this basic functionality hasn't been implemented.
Yeah why hasn't this been implemented? Tags are generally useless without searching by them. That's often the whole point of tags in any system.
- added a commit that references this issue
on May 9, 2022 - added 2 commits that reference this issue
on May 17, 2022 yay! \o/
- added a commit that references this issue
on Nov 22, 2025
Currently to find files/folders with a particular tag within NextCloud you need to go to the "Tags" menu option then type in or select the tag(s) that you want to filter with.
Using the search function, it is not possible to search for files/folders with a specified tag as it does a full text search of the files, but not the associated tag.
Can the search function be enhanced to search for not only the full text/file names but also for the tag(s) associated with a file? Another possible enhancement of the search can be to search for keywords entered in the search function within the comments associated with a file/folder