2011-01-23 06:09:13 +01:00
|
|
|
<?php
|
|
|
|
|
Remove PHID database, add Harbormaster database
Summary:
- We currently write every PHID we generate to a table. This was motivated by two concerns:
- **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do.
- **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type.
- We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461).
- Drop the PHID database.
- Introduce a "Harbormaster" database (the eventual CI tool, after Drydock).
- Add a scratch table to the Harbormaster database for doing unit test meta-tests.
- Now, PHID generation does no writes, and unit tests are isolated from the application.
- @csilvers: This should slightly improve the performance of the large query-bound tail in D2457.
Test Plan: Ran unit tests. Ran storage upgrade.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: csilvers, aran, nh, edward
Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
|
|
|
final class PhabricatorPHID {
|
2011-01-23 06:09:13 +01:00
|
|
|
|
|
|
|
protected $phid;
|
|
|
|
protected $phidType;
|
|
|
|
protected $ownerPHID;
|
|
|
|
protected $parentPHID;
|
|
|
|
|
Remove PHID database, add Harbormaster database
Summary:
- We currently write every PHID we generate to a table. This was motivated by two concerns:
- **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do.
- **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type.
- We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461).
- Drop the PHID database.
- Introduce a "Harbormaster" database (the eventual CI tool, after Drydock).
- Add a scratch table to the Harbormaster database for doing unit test meta-tests.
- Now, PHID generation does no writes, and unit tests are isolated from the application.
- @csilvers: This should slightly improve the performance of the large query-bound tail in D2457.
Test Plan: Ran unit tests. Ran storage upgrade.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: csilvers, aran, nh, edward
Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
|
|
|
public static function generateNewPHID($type) {
|
2011-01-23 06:09:13 +01:00
|
|
|
if (!$type) {
|
|
|
|
throw new Exception("Can not generate PHID with no type.");
|
|
|
|
}
|
|
|
|
|
Replace callsites to sha1() that use it to asciify entropy with
Filesystem::readRandomCharacters()
Summary: See T547. To improve auditability of use of crypto-sensitive hash
functions, use Filesystem::readRandomCharacters() in place of
sha1(Filesystem::readRandomBytes()) when we're just generating random ASCII
strings.
Test Plan:
- Generated a new PHID.
- Logged out and logged back in (to test sessions).
- Regenerated Conduit certificate.
- Created a new task, verified mail key generated sensibly.
- Created a new revision, verified mail key generated sensibly.
- Ran "arc list", got blocked, installed new certificate, ran "arc list"
again.
Reviewers: jungejason, nh, tuomaspelkonen, aran, benmathews
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Differential Revision: 1000
2011-10-11 04:22:30 +02:00
|
|
|
$uniq = Filesystem::readRandomCharacters(20);
|
Remove PHID database, add Harbormaster database
Summary:
- We currently write every PHID we generate to a table. This was motivated by two concerns:
- **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do.
- **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type.
- We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461).
- Drop the PHID database.
- Introduce a "Harbormaster" database (the eventual CI tool, after Drydock).
- Add a scratch table to the Harbormaster database for doing unit test meta-tests.
- Now, PHID generation does no writes, and unit tests are isolated from the application.
- @csilvers: This should slightly improve the performance of the large query-bound tail in D2457.
Test Plan: Ran unit tests. Ran storage upgrade.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: csilvers, aran, nh, edward
Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
|
|
|
return 'PHID-'.$type.'-'.$uniq;
|
2011-01-23 06:09:13 +01:00
|
|
|
}
|
|
|
|
|
2012-08-03 20:41:33 +02:00
|
|
|
public static function fromObjectName($name) {
|
|
|
|
$object = null;
|
|
|
|
$match = null;
|
|
|
|
if (preg_match('/^PHID-[A-Z]+-.{20}$/', $name)) {
|
|
|
|
// It's already a PHID! Yay.
|
|
|
|
return $name;
|
|
|
|
}
|
|
|
|
if (preg_match('/^r([A-Z]+)(\S*)$/', $name, $match)) {
|
|
|
|
$repository = id(new PhabricatorRepository())
|
|
|
|
->loadOneWhere('callsign = %s', $match[1]);
|
|
|
|
if ($match[2] == '') {
|
|
|
|
$object = $repository;
|
|
|
|
} else if ($repository) {
|
|
|
|
$object = id(new PhabricatorRepositoryCommit())->loadOneWhere(
|
|
|
|
'repositoryID = %d AND commitIdentifier = %s',
|
|
|
|
$repository->getID(),
|
|
|
|
$match[2]);
|
|
|
|
if (!$object) {
|
|
|
|
try {
|
|
|
|
$object = id(new PhabricatorRepositoryCommit())->loadOneWhere(
|
|
|
|
'repositoryID = %d AND commitIdentifier LIKE %>',
|
|
|
|
$repository->getID(),
|
|
|
|
$match[2]);
|
|
|
|
} catch (AphrontQueryCountException $ex) {
|
2012-08-03 20:47:53 +02:00
|
|
|
// Ambiguous; return nothing.
|
2012-08-03 20:41:33 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (preg_match('/^d(\d+)$/i', $name, $match)) {
|
|
|
|
$object = id(new DifferentialRevision())->load($match[1]);
|
|
|
|
} else if (preg_match('/^t(\d+)$/i', $name, $match)) {
|
|
|
|
$object = id(new ManiphestTask())->load($match[1]);
|
|
|
|
}
|
|
|
|
if ($object) {
|
|
|
|
return $object->getPHID();
|
|
|
|
}
|
|
|
|
return null;
|
|
|
|
}
|
2011-01-23 06:09:13 +01:00
|
|
|
}
|