Server: Use the search bar to search for files by tag

Created on 6 Jul 2016  路  13Comments  路  Source: nextcloud/server

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

1. to develop enhancement files search

Most helpful comment

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.

All 13 comments

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

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.

@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/10

The 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:
chrome_2019-06-19_01-43-45

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.
AnyDesk_2019-06-19_01-57-03
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.systemtagid

sql> 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.name for 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.

@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! :)

I absolutely can. I brought it here because it's directly a problem with implementing it. If you put it in, then the search bar would lock the whole page any time you clicked on it.

@rullzer @MorrisJobke @daita maybe you can give @da3dsoul some pointers? :)

17499 The optimization issue I made regarding this, for the sake of them having a reference to one another

Competely agree with the initial topic, ability to include tags in search would be a bless

Wait nextCloud has a Tagging ecosystem and the Search can't even filter based on tags? And this request was from 2016? How on earth did this happen? This is like Tagging functionality 101.

Can we PLEASE get Tag search functionality added already??? Like this is a really blatant shortcoming (not to mention how annoying it is to expose and then add tags per file).

Like, why bother tagging if it benefits me in no way in finding said content again? That's just asinine.

Was this page helpful?
0 / 5 - 0 ratings