-
Notifications
You must be signed in to change notification settings - Fork 2.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
add initial search in shared files #4207
Conversation
Merged build triggered. |
👍 |
fixes #744 |
Merged build finished. |
Test passed. |
Code makes sense 👍 |
@butonic How big is the risk for backporting? |
@karlitschek from a code perspective not big. The change is not very intrusive and the functions / classes I rely on are already there. I am a little unsure of the approach because a user might well have hundreds of thousands of files shared with him. At some point the SQL query will become too long for the RDBMS to handle because the so ... no risk, unless people share too many files ;) |
@butonic iirc MySQL has 1000 placeholders as a limit. @DeepDiver1975 fixed something related to it some time ago. Should we show these tons of files in dropdown anyway? UPD here is his PR #271 |
@owncloud-bot retest this please |
Build started. |
A test with 500000 parameters in the IN operator: http://stackoverflow.com/a/15588172/828717 Limiting the number of search results should also be done in the filecache, so I vote for doing that in a separate PR. |
@butonic yes, it's sqlite-related, I built similar query, the result is below:
#0 /home/deo/public_html/oc-test/lib/public/db.php(45): OC_DB::prepare('SELECT * from |
and quote from PR I linked above:
|
@VicDeo I split the ids into chunks of 1k. I also planned to add test to the shared cache tests ... but non are existing. @MTGap could you copy |
Test passed. |
@VicDeo bump for thumb? |
@butonic it does search and show the results. Is it ok that there is a 404 page once shared entry is clicked? |
@VicDeo nope, not ok, investigating. |
Test passed. |
@VicDeo this fixes the problem. @DeepDiver1975 please review if you want to search in shared files. @karlitschek can now be backported without risk as the SQL is chunked into queries with max 1k params in the LIKE clause. |
@butonic 👍 Tested |
I realize that this code is tested for master (eventually OC6?), but because of comment by @butonic about backporting, I stuck it into OC 5.0.10. On up-to-date CentOS 6, Apache, MySQL, I get nothing. By nothing, I mean that it doesn't log anything in owncloud.log, access.log, error.log, etc. There's no search drop-down or any indication that it's attempting to look, though top does report that mysqld is utilizing 100% CPU. It does continue to return results for owned files, but nothing for shared. I've been in a shared directory, entered the title of a .jpg file, and still get nothing. So, nothing broken apparently, but also, nothing gained. :-( |
|
||
$ids = \OCP\Share::getItemsSharedWith('file', \OC_Share_Backend_File::FORMAT_GET_ALL); | ||
foreach ($ids as $file) { | ||
$folderBackend = \OCP\Share::getBackend('folder'); |
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.
Maybe do this outside the foreach? or does getChildren change the state?
@karlitschek @VicDeo @bartv2 @DeepDiver1975 @MTGap the shared cache uses getAll() when searching for files, either by mime or by pattern (added with this PR). IMO, getAll() did not work as expected. I assumed it would return all file ids in a share. Seems that is not the case. So I moved the getChildren code to getAll and used that in the search methods. Looking at searchbymime I got the feeling that the code has not been maintained. The returned paths are wrong and the mimetype is only returning our internal numbers. Looking at the implementation of the filecache that is clearly wrong. Fixed that as well. Please review! |
searchByMime is used by pictures, documents, impress, impressionist, movies and reader. Tested with documents and pictures ... btw @karlitschek can we move gallery / pictures to it's own repo and complete the renaming? It's awkward to search for pictures / gallery and I never find what I'm looking for. It is already called pictures in the ui? Can I haz a separate repo? |
@owncloud-bot retest this please |
Test passed. |
|
||
while ($row = $result->fetchRow()) { | ||
if (substr($row['path'], 0, 6)==='files/') { | ||
$row['path'] = substr($row['path'],6); // remove 'files/' from path as it's relative to '/Shared' |
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's wrong. I'll just fix these methods in #4382.
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.
What's the status of this?
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.
@icewind1991 To me it seems correct for #4516
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.
But it seems to only work from search results that originates from the main store of the user, I think any result originating from an external storage will still have an incorrect path
For a proper fix, the mountpoint of for the storage which holds the search result should be compared with the user home folder
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.
afaict files and files_external use / as the root for their mountpoints. only the files_sharing cache returns results prefixed with 'Shared'. feel free to give a code example or highjack this PR. what would a test for this look like?
What would the fix look like for the 'old' sharing implementation? |
@MTGap what exactly is wrong? The view prepends search results with the path corresponding to the mountpoint / storage. The shared cache should only return the relative path, which is what the code above does. Conditionally. So this is a viable PR to fix broken behaviour which I need in pictures and documents. |
Yes, but your implementation doesn't work with other mount points or different file targets. |
@MTGap What other mount points use sharing as the file cache backend? We only have one 'Shared' folder. To my knowledge files_external backends uses searchCommon which I already pointed to: https://github.com/owncloud/core/blob/master/lib/files/view.php#L988 handles prepending the path with the mount points location in the file tree. What do you mean by file targets? The sharing cache only handles files, doesn't it? gallery shares / items are stored in the share table. This PR fixes all file based search results and does not break anything to my knowledge. Please give examples for any problems you see. |
I'm talking about shared files that are located in external storage. And file targets are unique file names for the user shared with that are not necessarily the same name as for the owner of the file. |
@MTGap AFAICT the sharing cache does not return results from eg. search_lucene, encryption, or the gallery that have a path starting with those apps names respectively. Tested this with demo.owncloud.org as an external mount and reshared to another user. he can now find those files fine. Yes, this leaves the cornercase of files residing in a literal 'files' folder. But this is something. |
Test passed. |
Better check this code in OC5 with shared folders that have spaces. A reboot brought it back up, but I was getting blank pages until the reboot. |
…in external storages
@owncloud-bot retest this please |
Rebased, tested, still 👍 from me, waiting for CI server @gah242s can't reproduce with master but we will be careful with backporting |
Test passed. |
@DeepDiver1975 @icewind1991 can we finally have it? |
tested 👍 |
ensure getChildren() is called on an instance of Share_Backend_Collection
Test passed. |
add initial search in shared files
@MTGap @icewind1991 customers start to ask for this. Not the best way to implement it because I use the folder backend get the children ids and then use those in a
IN (?,...,?)
SQL statement. This limits this implementation to the supported maximum length for a sql query ... which will be database specific. But it is a first implementation. I don't understand the sharing code well enough to implement a JOIN based implementation (actually that currently won't be possible because we have to recursively collect the children in a folder before we can filter their filename).@karlitschek @DeepDiver1975 @bartv2 please review.