Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce pagination in files-filter report #26507
Allow pagination when listing files
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
referenced this pull request
Nov 11, 2016
Test report report.xml:
<?xml version="1.0" encoding="utf-8" ?> <oc:filter-files xmlns:a="DAV:" xmlns:oc="http://owncloud.org/ns" > <a:prop> <a:getetag/> </a:prop> <oc:limit page="0" size="10" /> </oc:filter-files>
% curl -u admin:admin -X REPORT -H "Content-Type: text/xml" --data-binary "@report.xml" 'http://localhost/owncloud/remote.php/dav/files/admin/'
Some concerns: the regular filter report returns a flat list of files from all folders. This flat list can be paginated in this report, this is fine.
However we will also need a paginated call for folder-specific contents, without recursing. Should we make a separate report time for this maybe ? Or add a property
@DeepDiver1975 I've rebased this.
Also I discovered today that Sabre has a shorter way of compiling results from multiple nodes using
There will still be a performance issue here because we need to resolve every node individually.
Side note: if we ever implement Webdav sync it also uses
Arghh, no, not good.
I suspect that the old implementation also suffered from this. Since we have the files API node already, we should already be able to wrap it (it's a
I'll revert my commit because it will degrade the performance. From what I see we already had created the matching Sabre File and Directory in
More about this in a minute after the revert...
So, I've reverted the commit instead of deleting it, in case we still want it. (Squashing will kill it later).
Now looking at
However if we want REPORT to be used for pagination on simple folders, then we need a different approach there. Usually calling
So to solve the above question we really need to discuss "recursive / flattened / arbitrary results" vs "only show results from the current folder".
One idea would be to provide one generic REPORT type that only does a PROPFIND on the files endpoints (or even any part of the tree!) and paginates whatever the PROPFIND /
Then we provide another REPORT, which is the one from this PR, to really do search-like queries. In such queries the results are not limited to the current folder, so we have to use
Or a hybrid variant is to have a single REPORT type but with a
@DeepDiver1975 thoughts ?
Regarding recursive vs children, I think we could even call them differently:
Also I found a way to simplify the response code to use a more Sabr-y way to do it: c355695
All discovered while working on the customgroups REPORT: owncloud/customgroups#27.
Note: in the customgroups pagination I used a different format for the search pattern + pagination:
<?xml version="1.0" encoding="utf-8" ?> <oc:search-query xmlns:a="DAV:" xmlns:oc="http://owncloud.org/ns"> <a:prop> <oc:role></oc:role> <oc:display-name></oc:display-name> </a:prop> <oc:search> <oc:pattern>us</oc:pattern> <oc:limit>5</oc:limit> <oc:offset>0</oc:offset> </oc:search> </oc:search-query>
Rebased and pushed some changes:
Next up: integration tests for pagination when filtering.
changed the title from
[WIP] Introduce pagination in files-filter report
Introduce pagination in files-filter report
Mar 20, 2017
There aren't many changes there so I think it's ok.
Basically the response stays the same except that the array we pass there is sliced.
@jvillafanez adjusted, see last two commits