diff options
| author | Lars Wirzenius <liw@liw.fi> | 2022-04-09 09:40:59 +0300 |
|---|---|---|
| committer | Lars Wirzenius <liw@liw.fi> | 2022-04-16 09:06:05 +0300 |
| commit | 82ff782fe85c84c10f1f18c9bd5c2b017bc2f240 (patch) | |
| tree | dee4767299a179067b9b54d557e96f95af88801c /obnam.md | |
| parent | d9b72ffa5485f3c253da22f09ff0a7090de7aa37 (diff) | |
| download | obnam2-82ff782fe85c84c10f1f18c9bd5c2b017bc2f240.tar.gz | |
feat! change how chunk labels are serialized
Serialized labels now start with a type prefix: a character that says
what type of label it is.
This isn't strictly required: we _can_ just decide to always use a
single type of checksum for all chunks in one backup, for one client,
or in the whole repository. However, if it's ever possible to have
more than one type, it helps debugging if every checksum, when
serialized, is explicit about its type.
Change things to use the new serialize method instead of the Display
trait for Label. We're primarily serializing labels so they can be
stored in a database, and used in URLs, only secondarily showing them
to users.
Sponsored-by: author
Diffstat (limited to 'obnam.md')
| -rw-r--r-- | obnam.md | 20 |
1 files changed, 10 insertions, 10 deletions
@@ -1092,7 +1092,7 @@ storage of backed up data. ~~~scenario given a working Obnam system and a file data.dat containing some random data -when I POST data.dat to /v1/chunks, with chunk-meta: {"label":"abc"} +when I POST data.dat to /v1/chunks, with chunk-meta: {"label":"0abc"} then HTTP status code is 201 and content-type is application/json and the JSON body has a field chunk_id, henceforth ID @@ -1105,17 +1105,17 @@ We must be able to retrieve it. when I GET /v1/chunks/<ID> then HTTP status code is 200 and content-type is application/octet-stream -and chunk-meta is {"label":"abc"} +and chunk-meta is {"label":"0abc"} and the body matches file data.dat ~~~ We must also be able to find it based on metadata. ~~~scenario -when I GET /v1/chunks?label=abc +when I GET /v1/chunks?label=0abc then HTTP status code is 200 and content-type is application/json -and the JSON body matches {"<ID>":{"label":"abc"}} +and the JSON body matches {"<ID>":{"label":"0abc"}} ~~~ Finally, we must be able to delete it. After that, we must not be able @@ -1128,7 +1128,7 @@ then HTTP status code is 200 when I GET /v1/chunks/<ID> then HTTP status code is 404 -when I GET /v1/chunks?label=abc +when I GET /v1/chunks?label=0abc then HTTP status code is 200 and content-type is application/json and the JSON body matches {} @@ -1151,7 +1151,7 @@ We must get an empty result if searching for chunks that don't exist. ~~~scenario given a working Obnam system -when I GET /v1/chunks?label=abc +when I GET /v1/chunks?label=0abc then HTTP status code is 200 and content-type is application/json and the JSON body matches {} @@ -1178,7 +1178,7 @@ First, create a chunk. ~~~scenario given a working Obnam system and a file data.dat containing some random data -when I POST data.dat to /v1/chunks, with chunk-meta: {"label":"abc"} +when I POST data.dat to /v1/chunks, with chunk-meta: {"label":"0abc"} then HTTP status code is 201 and content-type is application/json and the JSON body has a field chunk_id, henceforth ID @@ -1194,10 +1194,10 @@ given a running chunk server Can we still find it by its metadata? ~~~scenario -when I GET /v1/chunks?label=abc +when I GET /v1/chunks?label=0abc then HTTP status code is 200 and content-type is application/json -and the JSON body matches {"<ID>":{"label":"abc"}} +and the JSON body matches {"<ID>":{"label":"0abc"}} ~~~ Can we still retrieve it by its identifier? @@ -1206,7 +1206,7 @@ Can we still retrieve it by its identifier? when I GET /v1/chunks/<ID> then HTTP status code is 200 and content-type is application/octet-stream -and chunk-meta is {"label":"abc"} +and chunk-meta is {"label":"0abc"} and the body matches file data.dat ~~~ |