Conversation
carlobeltrame
force-pushed
the
shared-camps-with-filters
branch
5 times, most recently
from
42c095b to
e163435
Compare
carlobeltrame
force-pushed
the
shared-camps-with-filters
branch
4 times, most recently
from
dca3ec0 to
13e558d
Compare
Follow-up for ecamp#8004 Querying by isPrototype OR isShared is slow, because databases don't like OR conditions too much. We work around this by adding a combined isPublic field which is enforced to always contain isShared || isPrototype and have the DB queries filter by that.
carlobeltrame
force-pushed
the
shared-camps-with-filters
branch
from
13e558d to
f488958
Compare
| security: 'is_granted("CAMP_COLLABORATOR", camp) or | ||
| is_granted("CAMP_IS_SHARED", camp) or | ||
| is_granted("CAMP_IS_PROTOTYPE", camp)' | ||
| is_granted("CAMP_IS_PUBLIC", camp)' |
There was a problem hiding this comment.
When /camps/camp-id/camp_collaborations is accessed, and the camp has set 'isPublic', then this endpoint may be displayed, but as an empty array.
Am I correctly?
There was a problem hiding this comment.
Exactly. This allows the frontend to "fail" gracefully. If someone visits the team page (even though it's not in the menu), they will see an empty list
| $publicCampsQry = $queryBuilder->getEntityManager()->createQueryBuilder(); | ||
| $publicCampsQry->select('c'); | ||
| $publicCampsQry->from(Camp::class, 'c'); | ||
| $publicCampsQry->where($queryBuilder->expr()->orX('c.isPrototype = true', 'c.isShared = true')); |
| $queryBuilder->innerJoin("{$activity}.camp", 'camp'); | ||
| $this->filterByCampCollaboration($queryBuilder, $user); |
| $queryBuilder->andWhere( | ||
| $queryBuilder->expr()->orX( | ||
| $queryBuilder->expr()->andX( | ||
| "{$rootAlias}.campCollaboration IS NULL", | ||
| $queryBuilder->expr()->in("{$rootAlias}.camp", $publicCampsQry->getDQL()) | ||
| ), | ||
| $queryBuilder->expr()->in("{$rootAlias}.camp", $campsQry->getDQL()) | ||
| ) | ||
| ); | ||
| $queryBuilder->setParameter('current_user', $user); |
There was a problem hiding this comment.
This could become a performance issue.
If that is the case, we will have to create our own view.
for each user ID, all visible materialist IDs:
[user] * [non-personal materiallists of public camps]
union
[user] -< [campcollaboration] -> [camp] -< [materiallist]
There was a problem hiding this comment.
Actually, the discussion about the reliability of material_list.camp_collaboration is still open.
see:
#5537 | #5537 (comment)
2 participants
Extension of #8004, which fulfils the following requirement:
As per discussion, first merge #8004 and check the performance, then maybe merge this and check the performance again.
To be discussed / decided / done: