Page MenuHomePhabricator

Add controllers/search/edit engine functionality to RepositoryIdentity
ClosedPublic

Authored by amckinley on May 5 2018, 3:23 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 23, 5:47 AM
Unknown Object (File)
Sun, Dec 15, 4:55 PM
Unknown Object (File)
Thu, Dec 12, 1:32 AM
Unknown Object (File)
Sun, Dec 8, 3:48 PM
Unknown Object (File)
Sat, Dec 7, 1:42 AM
Unknown Object (File)
Tue, Dec 3, 4:11 PM
Unknown Object (File)
Mon, Dec 2, 8:08 PM
Unknown Object (File)
Mon, Dec 2, 8:08 PM
Subscribers
Restricted Owners Package

Details

Summary

Depends on D19423. Ref T12164. Adds controllers capable of listing and editing PhabricatorRepositoryIdentity objects. Starts creating those objects when commits are parsed.

Test Plan

Reparsed some revisions, observed objects getting created in the database. Altered some Identity objects using the controllers and observed effects in the database. No attempts made to validate behavior under "challenging" author/committer strings.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Owners added a subscriber: Restricted Owners Package.May 5 2018, 3:23 AM

This all looks great to me, with one minor inline about possible race behavior.

src/applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php
80

There is some possibility that this save() could race, if two workers are parsing different commits by the same author:

  • Both look for the Identity and don't find it.
  • Both build a new Identity and save it.
  • Whichever one is slower loses.

In this case, the slower INSERT will hit AphrontDuplicateKeyQueryException when the second row collides with the first row on the UNIQUE KEY on nameHash.

I don't have a great solution for this. Where it comes up elsewhere, I think we usually use this pattern:

thing = load(id);
if (!thing) {
  thing = new(id);
  try {
    thing->save();
  } catch (duplicate) {
    thing = load(id);
    if (!thing) {
      throw new Exception("Raced and lost, then failed to load the object we lost the race to? Very confusing.");
    }
  }
}

This doesn't feel very elegant, but should survive anything reasonable.

This revision is now accepted and ready to land.May 5 2018, 3:31 PM

No attempts made to validate behavior under "challenging" author/committer strings.

This doesn't need to be vetted too heavily, no install has actually managed to produce any of these so far that I'm aware of (although I'm just sure one will some day) and I'm pretty confident this pattern works (if it doesn't, we'll have to fix a few other things too).

Also, if workers do race the one that lost the race should just retry, so the race is harmless, just not ideal (and will stick a potentially confusing error in the error log).

remove ferret implementation

This revision was automatically updated to reflect the committed changes.