Page MenuHomeSoftware Heritage
Files F7343118

D5381.id.diff
No OneTemporary
Actions

D5381.id.diff
View Options

diff --git a/docs/specs/index.rst b/docs/specs/index.rst
--- a/docs/specs/index.rst
+++ b/docs/specs/index.rst
@@ -10,5 +10,4 @@
blueprint.rst
spec-loading.rst
protocol-reference.rst
- spec-technical.rst
spec-meta-deposit.rst
diff --git a/docs/specs/spec-technical.rst b/docs/specs/spec-technical.rst
deleted file mode 100644
--- a/docs/specs/spec-technical.rst
+++ /dev/null
@@ -1,96 +0,0 @@
-Technical specifications
-========================
-
-Requirements
-~~~~~~~~~~~~
-
-* one dedicated database to store the deposit's state - swh-deposit
-* one dedicated temporary storage to store archives before loading
-* one client to test the communication with SWORD protocol
-
-Deposit reception schema
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-* SWORD imposes the use of basic authentication, so we need a way to
- authenticate client. Also, a client can access collections:
-
- **deposit\_client** table:
-
- - id (bigint): Client's identifier
- - username (str): Client's username
- - password (pass): Client's encrypted password
- - collections ([id]): List of collections the client can access
-
-* Collections group deposits together:
-
- **deposit\_collection** table:
-
- - id (bigint): Collection's identifier
- - name (str): Collection's human readable name
-
-* A deposit is the main object the repository is all about:
-
- **deposit** table:
-
- - id (bigint): deposit's identifier
- - reception\_date (date): First deposit's reception date
- - complete\_data (date): Date when the deposit is deemed complete and ready
- for loading
- - collection (id): The collection the deposit belongs to
- - external id (text): client's internal identifier (e.g hal's id, etc...).
- - client\_id (id) : Client which did the deposit
- - swh\_id (str) : swh identifier result once the loading is complete
- - status (enum): The deposit's current status
-
-- As mentioned, a deposit can have a status, whose possible values are:
-
- .. code:: text
-
- 'partial', -- the deposit is new or partially received since it
- -- can be done in multiple requests
- 'expired', -- deposit has been there too long and is now deemed
- -- ready to be garbage collected
- 'deposited' -- deposit complete, it is ready to be checked to ensure data consistency
- 'verified', -- deposit is fully received, checked, and ready for loading
- 'loading', -- loading is ongoing on swh's side
- 'done', -- loading is successful
- 'failed' -- loading is a failure
-
-* A deposit is stateful and can be made in multiple requests:
-
- **deposit\_request** table:
-
- - id (bigint): identifier
- - type (id): deposit request's type (possible values: 'archive', 'metadata')
- - deposit\_id (id): deposit whose request belongs to
- - metadata: metadata associated to the request
- - date (date): date of the requests
-
- Information sent along a request are stored in a ``deposit_request`` row.
-
- They can be either of type ``metadata`` (atom entry, multipart's atom entry
- part) or of type ``archive`` (binary upload, multipart's binary upload part).
-
- When the deposit is complete (status ``deposited``), those ``metadata`` and
- ``archive`` deposit requests will be read and aggregated. They will then be
- sent as parameters to the loading routine.
-
- During loading, some of those metadata are kept in the ``origin_metadata``
- table and some other are stored in the ``revision`` table (see `metadata
- loading <#metadata-loading>`__).
-
- The only update actions occurring on the deposit table are in regards of:
-
- - status changes (see figure below):
-
- - ``partial`` -> {``expired``/``deposited``},
- - ``deposited`` -> {``rejected``/``verified``},
- - ``verified`` -> ``loading``
- - ``loading`` -> {``done``/``failed``}
-
- - ``complete_date`` when the deposit is
- finalized (when the status is changed to ``deposited``)
- - ``swh-id`` is populated once we have the loading result
-
-.. figure:: ../images/status.svg
- :alt:

File Metadata

Mime Type
text/plain
Expires
Mar 17 2025, 7:31 PM (7 w, 3 d ago)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
3215906

Event Timeline

About · Developer information · Legal