When the migrator renames a table, for example for upgrade simulation,
it should not rename the primary key to avoid messing up with the diff
because the MySQL Doctrine code expects that index to always be called
"primary".
This functions are deprecated and/or removed since ownCloud 7. Additionally a issubdirectory check has been added here to prevent developers to use this function in a potentially insecure way.
Port of https://github.com/owncloud/core/pull/9033
add a function getUserGroupIds for retrieving group ids instead of group objects. this significantly improves performance when using many (nested) groups.
Changes a function call in getUserGroups to only retrieve group ids instead of objects.
this change significantly improves performance when using owncloud with many groups, e.g. nested ldap hierarchy (1.2.840.113556.1.4.1941), since getUserGroups gets called in oc_share::getItems, which is needed for every page request.
in my particular case, it took more than 10s to load the calendar page and more than 6s to load the file page.
this was in an environment with 100 user groups (nested) per user. The performance was bad due to the following call stack:
self::getManager()->getUserGroups($user)
- getGroupObject() (executed for every group!)
- groupExists() (resulting in many ldap-requests)
since the groups are loaded from ldap, it is unnecessary to check whether the group exists or not.
The updater is using "before update" repair steps and "regular" repair
steps.
The "regular" repair steps are also used by the CLI tool.
Currently no steps exist but can be added later in the static methods in
the \OC\Repair class.
Added unit test to test messaging, error and exception cases.
Changes a function call in getUserGroups to only retrieve group ids instead of objects.
this change significantly improves performance when using owncloud with many groups, e.g. nested ldap hierarchy (1.2.840.113556.1.4.1941), since getUserGroups gets called in oc_share::getItems, which is needed for every page request.
in my particular case, it took more than 10s to load the calendar page and more than 6s to load the file page.
this was in an environment with 100 user groups (nested) per user. The performance was bad due to the following call stack:
self::getManager()->getUserGroups($user)
- getGroupObject() (executed for every group!)
- groupExists() (resulting in many ldap-requests)
since the groups are loaded from ldap, it is unnecessary to check whether the group exists or not.
add a function getUserGroupIds for retrieving group ids instead of group objects. this significantly improves performance when using many (nested) groups.
macjohnny
Jenkins for ownCloud
Lukas Reschke
icewind1991
Vincent Petry
Andreas Fischer
Robin Appelman
Jörn Friedrich Dreyer
Georg Ehrke
Arthur Schiwon
Morris Jobke
Frank Karlitschek