gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: simplified database schema


From: gnunet
Subject: [taler-docs] branch master updated: simplified database schema
Date: Tue, 11 Oct 2022 11:11:44 +0200

This is an automated email from the git hooks/post-receive script.

oec pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 6acc6b8  simplified database schema
6acc6b8 is described below

commit 6acc6b8b94dde459d30df2e3fbf8be5a3c30f117
Author: Özgür Kesim <oec-taler@kesim.org>
AuthorDate: Tue Oct 11 11:11:40 2022 +0200

    simplified database schema
---
 design-documents/028-deposit-policies.rst | 54 ++++++++++++++-----------------
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/design-documents/028-deposit-policies.rst 
b/design-documents/028-deposit-policies.rst
index be84035..0dd7c62 100644
--- a/design-documents/028-deposit-policies.rst
+++ b/design-documents/028-deposit-policies.rst
@@ -57,7 +57,7 @@ TODO, explain:
 - Naming conventions for policy extensions
 - Deadlines and -handling
 - API-endpoints (``/extensions/policy_...``)
-- Typical choreography of a deposit with policy and its fulfilment
+- Typical choreography of a deposit with policy and its fulfillment
 
 Database-schema
 ===============
@@ -87,60 +87,56 @@ TODO: Description
                 label=<<B>policy_details</B>>
                 margin=20
                 policy_details [
-                  label="<id>id\l|<hash>hash_code 
(unique)\l|deadline\l|commitment (amount)\l|accumulated_total (amount)\l|fee 
(amount)\l|transferable (amount)\l|fulfilment_state\l"
+                  label="<id>id\l|<hash>hash_code 
(unique)\l|deadline\l|commitment (amount)\l|accumulated_total (amount)\l|fee 
(amount)\l|transferable (amount)\l|fulfillment_state\l"
                 ]
         }
 
-        subgraph cluster_policy_fulfilments {
-                label=<<B>policy_fulfilments</B>>
+        subgraph cluster_policy_fulfillments {
+                label=<<B>policy_fulfillments</B>>
                 margin=20
                 rank=min;
-                policy_fulfilments [
-                  label="<id>id\l|proof\l|timestamp\l"
-                ]
-        }
-
-        subgraph cluster_policy_details_fulfilments {
-                label=<<B>policy_details_fulfilments</B>>
-                margin=20
-                policy_details_fulfilments [
-                  
label="<ref_details>hash_code\l|<ref_fulfilments>fulfilment_id\l"
+                policy_fulfillments [
+                  label="<id>id\l|proof\l|timestamp\l|<codes>policy_hash_codes 
(blob)\l"
                 ]
         }
 
         deposits:ref->policy_details:id [ label="n:1"; fontname="monospace" ];
-        policy_details:hash->policy_details_fulfilments:ref_details [ 
dir=back; label="1:1"; fontname="monospace" ];
-        policy_details_fulfilments:ref_fulfilments->policy_fulfilments:id [ 
label="n:1"; fontname="monospace" ];
-
+        policy_details:hash->policy_fulfillments:codes [ label="quasi n:1"; 
fontname="monospace"; dir=back; style=dashed];
    }
 
-Policy Fulfilment States
-========================
 
-The fulfilment of a policy can be in one of the following five states:
+The entry ``policy_hash_codes`` in table ``policy_fulfillment`` is a binary 
blob
+that consists of the concatenation of all ``hash_code``'s from the
+``policy_details`` that are fulfilled by this proof.
+
+
+Policy Fulfillment States
+=========================
+
+The fulfillment of a policy can be in one of the following five states:
 
 Ready
         The policy is funded and ready. The exchange is waiting for a proof of
-        fulfilment to arrive before the deadline.
+        fulfillment to arrive before the deadline.
 
 Insufficient
         The policy lacks funding, that is ``accumulated_total`` <
         ``commitment``, but has otherwise been accepted.  Funding can be
-        continued by calling ``/deposit`` with more coins and the same policy
-        details.
+        continued by calling ``/deposit`` or ``/batch-deposit`` with more coins
+        and the same policy details.
 
 Success
         The policy is provably fulfilled.  The amounts for payout, fees and
-        refresh are transfered/can be claimed.  Note that a policy fulfilment
+        refresh are transfered/can be claimed.  Note that a policy fulfillment
         handler can change the values for the amounts for payout, fees and
         refresh.
 
 Timeout
-        The policy has timed out.  The amount for payout, free and refresh are
+        The policy has timed out.  The amounts for payout and refresh are
         transfered/can be claimed.
        
 Failure
-        The policy is in an failure state.  Payouts, fees and refreshes are
+        The policy is in an failure state.  Payouts and refreshes are
         blocked, timeouts are ignored.
 
 
@@ -150,14 +146,14 @@ Invariants
 
 The following invariants need to be fulfilled and be checked by the auditor:
 
-- The fulfilment state of a policy is **Insufficient** IF AND ONLY IF the
+- The fulfillment state of a policy is **Insufficient** IF AND ONLY IF the
   amount in ``commitment`` is larger than the amount in ``accumulated_total``.
 
 - The sum of amounts in ``fee`` and ``transferable`` must be less or equal to
   the amount in ``accumulated_total``.
 
-- If the fulfilment state of a policy is **Success**, there MUST exists an
-  entry in the ``policy_details_fulfilment`` table for the corresponding
+- If the fulfillment state of a policy is **Success**, there MUST exists an
+  entry in the ``policy_details_fulfillment`` table for the corresponding
   ``hash_code``.
 
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]