Page MenuHomePhabricator

Materialize parent project memberships
ClosedPublic

Authored by epriestley on Dec 23 2015, 5:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Sep 16, 8:06 PM
Unknown Object (File)
Thu, Sep 8, 11:22 AM
Unknown Object (File)
Aug 20 2022, 1:20 PM
Unknown Object (File)
Aug 15 2022, 11:33 AM
Unknown Object (File)
Aug 9 2022, 7:37 PM
Unknown Object (File)
Aug 5 2022, 2:44 AM
Unknown Object (File)
Aug 3 2022, 9:07 AM
Unknown Object (File)
Aug 2 2022, 2:14 AM
Subscribers

Details

Reviewers
chad
Maniphest Tasks
T10010: Implement Subprojects
Commits
Restricted Diffusion Commit
rP26ba4e871720: Materialize parent project memberships
Summary

Ref T10010. Subprojects have the following general membership rule: if you are a member of a subproject ("Engineering > Backend"), you are also a member of the parent project.

It would be unreasonably difficult to implement this rule directly in SQL when querying withMemberPHIDs(), because we'd have to do an arbitrarily large number of arbitrarily deep joins, or fetch and then requery a lot of data.

Instead, introduce "materailized members", which are just a copy of all the effective members of a project. When a subproject has a membership change, we go recompute the effective membership of all the parent projects. Then we can just JOIN to satisfy withMemberPHIDs().

Having this process avialable will also be useful in the future, when a project's membership might be defined by some external source.

Also make milestones mostly work like we'd expect them to with respect to membership and visibility.

Test Plan
  • Added and executed unit tests.
  • Changed project members, verified materialized members populated correctly in the database.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Materialize parent project memberships.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.Dec 23 2015, 9:23 PM
This revision was automatically updated to reflect the committed changes.
joshuaspence added inline comments.
src/applications/project/engineextension/PhabricatorProjectsMembershipIndexEngineExtension.php
3

Hmm, what does this have to do with indexing? I'm probably missing something since I think that this code is fairly new.

src/applications/project/query/PhabricatorProjectQuery.php
99

Hmm, where is this defined?

Brief rundown in "Index" is:

Before: "SearchEngine" did fulltext indexing, plus a few weird other hacky things like denormalizing project names into Maniphest and updating tokenizers. Was confusing with "ApplicationSearchEngine", and some of its duties didn't really make sense. Most "DocumentIndexers" were fairly copy-pastey; root class was full of instanceof, some locking/versioning issues.

Now: "IndexEngine" is "fulltext + other similar operations", where "similar operations" are updating other search indexes (conpherence threads, package ngrams, soon files ngrams, project ngrams, etc), materializing memberships (this diff) and whatever else fits. "FulltextEngine" is a subset of "Indexing", and just covers the MySQL Fulltext/Elastic stuff.

src/applications/project/query/PhabricatorProjectQuery.php
99

whoops