From 82ff782fe85c84c10f1f18c9bd5c2b017bc2f240 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sat, 9 Apr 2022 09:40:59 +0300 Subject: 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 --- obnam.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'obnam.md') diff --git a/obnam.md b/obnam.md index a02aacb..381802c 100644 --- a/obnam.md +++ b/obnam.md @@ -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/ 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 {"":{"label":"abc"}} +and the JSON body matches {"":{"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/ 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 {"":{"label":"abc"}} +and the JSON body matches {"":{"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/ 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 ~~~ -- cgit v1.2.1