Closed (fixed)
Project:
Group
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
17 Jan 2022 at 13:34 UTC
Updated:
24 Jan 2024 at 19:18 UTC
Jump to comment: Most recent, Most recent file
After #3254311: Denormalize group_type and plugin_id for GroupContent entity and add indexes, there are a lot of places where we can optimize the code by directly querying group content rather than first retrieving the group content types. We can also introduce #3040478: GroupContentStorage exceptions unnecessary(?) and/or undocumented in 2.0.x
Let's do that here in one big swoop.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | optimize-plugin-ids-query-3258942-10.patch | 1.55 KB | hungdo |
| #4 | group-3258942-4.patch | 21.34 KB | kristiaanvandeneynde |
Comments
Comment #2
kristiaanvandeneyndeNot touching the query access too much because we will rework that in #3204083: Rework group roles into a scoped system and adjust permission calculation
Comment #4
kristiaanvandeneyndeForgot to adjust a test.
Comment #5
kristiaanvandeneyndeComment #8
mvonfrie commentedWhere is the change record regarding the removal of the
$filtersparameter ofGroup::getContentEntities($plugin_id, $filters)(orGroup::getRelatedEntities($plugin_id, $filters)in 2.x/3.x)?How can I rewrite my code which uses the filters? In my case the filter depends on the bundle type of the related entities, for type A I have to filter on the group owner UID, for type B on the current user UID. And there are two more filters to apply, which are more difficult to explain.
Comment #9
kristiaanvandeneyndehttps://www.drupal.org/node/3258952
You can look into the method you were using and write a similar entity query.
Comment #10
hungdo commentedThe static query with distinct option consumes alot of memory in our site since our group_relationship_field_data table is roughly 200K records.
Attaching a patch that uses
GroupContentStorageInterface::loadByEntity()method instead.