matthiasbeyer/imag
1
0
Fork 0
Code Releases Activity

Revisit doc on entry version

Browse source 
We don't have that concept anymore, remove docs for it.
This commit is contained in:
Matthias Beyer 2017-10-14 15:28:42 +02:00
parent 494327e109
commit fcd30a80ad
1 changed files with 7 additions and 38 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
doc/src/02000-store.md
View file

@ -88,7 +88,7 @@ This is an example text, written by the user.
The "Entries" are stored as files in the "Store", which is a directory the
user has access to. The store may exist in the users Home-directory or any
other directory the user has read-write-Access to.
other directory the user has read-write-access to.
Each module stores its data in an own subdirectory in the store. This is because
we like to keep things ordered and clean, not because it is technically
@ -100,54 +100,23 @@ So if the store exists in `/home/user/store/`, a file with the storepath
`/example.file` is (on the filesystem) located at
`/home/user/store/example.file`.
A storepath contains predefined parts:
By convention, each `libimagentry<name>` and `libimag<name>` module stores its
entries in in `/<name/`.
* The module name of the Module the Entry belongs to, as said above.
This part is always a directory.
* The version (semantic versioning applies) of the module storing the entry.
This part is a postfix to the filename.
The pattern for the storepath is
So, the pattern for the storepath is
```
/<module name>/<optional sub-folders>/<file name>~<sem version>
/<module name>/<optional sub-folders>/<file name>
```
So if a module named "example-module" with version "0.1.0" stores a file in the
Store, the storepath for a file with the name "example" is
"/example-module/example~0.1.0".
Any number of subdirectories may be used, so creating folder hierarchies is
possible and valid. A file "example" for a module "module" in version "0.1.0"
possible and valid. A file "example" for a module "module"
would be stored in sub-folders like this:
```
/module/some/sub/folder/example~0.1.0
/module/some/sub/folder/example
```
For example, it is valid if these files exist at the same time:
* /foo/bar~0.2
* /foo/bar~1.3
It might not be sane, though.
To future-proof the system it is necessary to provide a way for modules to
differentiate in their versions on the store level. Thus if a module wants to
retrieve a file from the store it must at least accept files from it's current
advertised version. It may accept older files and it may transform them and
resubmit them in the newer version.
## Store path links {#sec:thestore:links}
Linking entries is version independent.
This means if an entry "a" from a module "A" gets written to the store, it may
link to an entry "b" from a module "B", which is in version "0.1.0" at the
moment. If the module "B" gets updated, it might update its entries in the store
as well. The link from the "a" should never get invalid in this case, though it
is not ensured by the core of imag itself.
## Backends {#sec:thestore:backends}
The store itself also has a backend. This backend is the "filesystem