This commit is contained in:
Fabian Kretzer 2021-08-11 16:34:49 +02:00 committed by GitHub
parent 4bddd67a46
commit 885a262657
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -76,7 +76,7 @@ where the former references objects that must exist in the database and the latt
### Serialization formats for codebase objects
Each of the object blob formats begins with a varint format id. For a given object type, different format ids indicate different ways of representing the same object -- not a way of representing a slightly different type of object. This enables us to make different storage-lager efficiency tradeoffs based on an object's contents or a user's access patterns.
Each of the object blob formats begins with a varint format id. For a given object type, different format ids indicate different ways of representing the same object -- not a way of representing a slightly different type of object. This enables us to make different storage-layer efficiency tradeoffs based on an object's contents or a user's access patterns.
These different formats are enumerated in `U.Codebase.Sqlite.{Term,Decl,Branch,Patch}.Format.hs` respectively, and collected below:
@ -247,4 +247,4 @@ data BranchLocalIds = LocalIds
`ObjectId`s are used to reference types and terms in the namespace. Note that they are not `HashId`s, because the namespace shouldn't be able to refer to definitions that aren't in the database.
`PatchObjectIds` reference the object ids of patch objects, as you might imagine.
`branchChildLookup` contains two fields: a `CausalHashId` which points to the history of the child, and the `BranchObjectId` which proves that the relevant namespace slice is also present. In general, a codebase may not have the namespace slice corresponding to every causal id, but it ought to have them for the children of another namespace slice it does have (thus, the `BranchObjectId` is used). The causal relationship stored relationally rather than as blobs, and the `CausalHashId` is a useful index into the `causal_parents` table.
`branchChildLookup` contains two fields: a `CausalHashId` which points to the history of the child, and the `BranchObjectId` which proves that the relevant namespace slice is also present. In general, a codebase may not have the namespace slice corresponding to every causal id, but it ought to have them for the children of another namespace slice it does have (thus, the `BranchObjectId` is used). The causal relationship stored relationally rather than as blobs, and the `CausalHashId` is a useful index into the `causal_parents` table.