mirror of
https://github.com/unisonweb/unison.git
synced 2024-09-11 10:35:57 +03:00
fix typo
This commit is contained in:
parent
4bddd67a46
commit
885a262657
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user