Page MenuHomePhabricator

Materialize parent project memberships

Authored by epriestley on Dec 23 2015, 5:12 PM.
Referenced Files
Unknown Object (File)
Dec 31 2022, 12:41 AM
Unknown Object (File)
Dec 26 2022, 2:26 AM
Unknown Object (File)
Dec 23 2022, 12:17 PM
Unknown Object (File)
Dec 14 2022, 11:45 PM
Unknown Object (File)
Dec 6 2022, 9:45 AM
Unknown Object (File)
Nov 29 2022, 8:30 PM
Unknown Object (File)
Nov 29 2022, 8:30 PM
Unknown Object (File)
Nov 29 2022, 8:30 PM


Maniphest Tasks
T10010: Implement Subprojects
Restricted Diffusion Commit
rP26ba4e871720: Materialize parent project memberships

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

rP Phabricator
Lint Not Applicable
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.

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


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.