Changeset View
Standalone View
src/applications/repository/storage/PhabricatorRepositoryIdentity.php
- This file was added.
| <?php | |||||
| final class PhabricatorRepositoryIdentity | |||||
| extends PhabricatorRepositoryDAO { | |||||
| protected $identityNameHash; | |||||
| protected $identityNameRaw; | |||||
epriestley: `phid` is added implicitly and doesn't need to be listed as a protected property. (If this was… | |||||
| protected $identityNameEncoding; | |||||
Done Inline ActionsThere's no natural epoch on identities so I think we can drop this. epriestley: There's no natural epoch on identities so I think we can drop this. | |||||
Not Done Inline ActionsI can think of lots of reasons we'd want to track the creation/modification of identities, but I guess adding transaction support will take care of that. amckinley: I can think of lots of reasons we'd want to track the creation/modification of identities, but… | |||||
Not Done Inline ActionsOh, CONFIG_TIMESTAMPS => true fixes this. amckinley: Oh, `CONFIG_TIMESTAMPS => true` fixes this. | |||||
Not Done Inline ActionsYeah, that plus transactions should give us pretty good records (and true should be the default so you can just omit the config completely, I believe). epriestley: Yeah, that plus transactions should give us pretty good records (and `true` should be the… | |||||
Done Inline ActionsUnless you have plans for it, I don't think we need an identityType -- there's only one type of identity. epriestley: Unless you have plans for it, I don't think we need an `identityType` -- there's only one type… | |||||
| protected $automaticGuessedUserPHID; | |||||
| protected $manuallySetUserPHID; | |||||
| protected $currentEffectiveUserPHID; | |||||
| protected function getConfiguration() { | |||||
| return array( | |||||
| self::CONFIG_AUX_PHID => true, | |||||
| self::CONFIG_BINARY => array( | |||||
| 'identityNameRaw' => true, | |||||
| ), | |||||
| self::CONFIG_COLUMN_SCHEMA => array( | |||||
Done Inline ActionsWe could let these have normal timestamps, I think. There shouldn't be all that many of them and I think they'll be fairly normal objects. epriestley: We could let these have normal timestamps, I think. There shouldn't be all that many of them… | |||||
| 'identityNameHash' => 'bytes12', | |||||
| 'identityNameEncoding' => 'text16?', | |||||
| 'automaticGuessedUserPHID' => 'phid?', | |||||
| 'manuallySetUserPHID' => 'phid?', | |||||
| 'currentEffectiveUserPHID' => 'phid?', | |||||
| ), | |||||
| self::CONFIG_KEY_SCHEMA => array( | |||||
| 'key_identity' => array( | |||||
| 'columns' => array('identityNameHash'), | |||||
| 'unique' => true, | |||||
| ), | |||||
| ), | |||||
| ) + parent::getConfiguration(); | |||||
| } | |||||
Not Done Inline ActionsSo should the unique column be on the hash or the raw value? Since we search by hash, I can see it making sense to make that column unique. amckinley: So should the unique column be on the hash or the raw value? Since we search by hash, I can see… | |||||
| public function getPHIDType() { | |||||
| return PhabricatorRepositoryIdentityPHIDType::TYPECONST; | |||||
| } | |||||
| } | |||||
Done Inline ActionsYou can omit this -- it's added automatically. Some older tables had an unusual key name, so they still specify it manually, but newer tables can just use the default stuff. epriestley: You can omit this -- it's added automatically.
Some older tables had an unusual key name, so… | |||||
Done Inline ActionsIn modern code, prefer overriding the slightly simpler getPHIDType(). epriestley: In modern code, prefer overriding the slightly simpler `getPHIDType()`. | |||||
phid is added implicitly and doesn't need to be listed as a protected property. (If this was copy/paste, the other one can be cleaned up too.)