Materialize parent project memberships
ClosedPublic
Actions

Authored by epriestley on Dec 23 2015, 5:12 PM.

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 updated this revision to Diff 35930.Dec 23 2015, 5:12 PM

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.

epriestley added a task: T10010: Implement Subprojects.

chad accepted this revision.Dec 23 2015, 9:23 PM

chad edited edge metadata.

This revision is now accepted and ready to land.Dec 23 2015, 9:23 PM

Closed by commit rP26ba4e871720: Materialize parent project memberships (authored by epriestley, committed by epriestley). · Explain WhyDec 23 2015, 10:39 PM

This revision was automatically updated to reflect the committed changes.

joshuaspence added a subscriber: joshuaspence.Dec 24 2015, 1:07 AM

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.