currently `[$userId, $rootId]` is used as the unique key for storing mounts in the mount cache,
however there are cases where the same rootid is mounted in multiple places for a user which currently leads to not all of those mounts being added to the cache.
Previously this didn't matter as the mount cache was only used to list users with access to a specific file, so a user having access to the file multiple times didn' change anything.
With 24 the mount cache is used for more cases and multiple mounts for the same id becomes relevant.
While I think there isn't a real negative effect atm besides missing the optimized path we should ensure that the mounts are properly listed
Signed-off-by: Robin Appelman <robin@icewind.nl>
having the index work properly for the queries we need it for requires some additional options which dbal does not support at the momement.
to prevent making it harder to add the correct index later on we don't create the index for now on postgresql
Signed-off-by: Robin Appelman <robin@icewind.nl>
The reason that `filecache.path` hasn't had an index added is the mysql limitation of ~1kb for indexeded fields,
which is to small for the `path`, however mysql supports indexing only the first N bytes of a column instead of the entire column,
allowing us to add an index even if the column is to long.
Because the index doesn't cover the entire column it can't be used in all situations where a normal index would be used, but it does cover the `path like 'folder/path/%'` queries that are used in various places.
Sqlite and Postgresql don't support prefix indexes, but they also don't have the 1kb limit and DBAL handles the differences in index creation.
Signed-off-by: Robin Appelman <robin@icewind.nl>
for the following query 'SELECT "path" FROM "oc_filecache" WHERE ("storage" = $storage) AND ("size" < 0) ORDER BY "fileid" DESC LIMIT 1;'
currently the database will in some cases decide to priorize the sort by fileid over the filter when picking what index to use, resulting in a much slower query.
by creating an index that allows first sorting by fileid and also filter by storage and size this case will be greatly sped up
Signed-off-by: Robin Appelman <robin@icewind.nl>
The reason that `filecache.path` hasn't had an index added is the mysql limitation of ~1kb for indexeded fields,
which is to small for the `path`, however mysql supports indexing only the first N bytes of a column instead of the entire column,
allowing us to add an index even if the column is to long.
Because the index doesn't cover the entire column it can't be used in all situations where a normal index would be used, but it does cover the `path like 'folder/path/%'` queries that are used in various places.
Sqlite and Postgresql don't support prefix indexes, but they also don't have the 1kb limit and DBAL handles the differences in index creation.
Signed-off-by: Robin Appelman <robin@icewind.nl>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
