1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-14 10:52:41 +01:00
phorge-phorge/src/applications/phid/storage/PhabricatorPHID.php

74 lines
2.2 KiB
PHP
Raw Normal View History

2011-01-23 06:09:13 +01:00
<?php
/*
* Copyright 2012 Facebook, Inc.
2011-01-23 06:09:13 +01:00
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
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.");
}
$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
}
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) {
// Ambiguous, no jump.
}
}
}
} 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
}