agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

remove contains only, and add attibute_assert

Browse source
This commit is contained in:
Stefan Schießl 2018-07-29 07:43:14 +02:00 committed by GitHub
parent 6df4a3824b
commit ba625b1cd3
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
bsip-0040.md
View file

@ -81,11 +81,11 @@ List of possible asserts are:
| `lt, le, gt, ge` | `comparative` | stateless | | `lt, le, gt, ge` | `comparative` | stateless |
| `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] | | `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] |
| `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] | | `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] |
| `contains_only` | [`list`, `of`, `allowed`, `fields`] | stateless | | `may_mutate` | `attribute_to_assert` = [{`attribute_identifier`: `any of above assert_objects`}] | stateless |
There is no implicit type conversion when attempting to assert, incompatible type means assert failure. There is no implicit type conversion when attempting to assert, incompatible type means assert failure.
In the following we list possible `asserts`. Mentioning `argument value` refers to the value of the argument of the operation specified `argument` in `assert_object`. In the following we list possible `asserts`. Mentioning `argument value` refers to the value of the argument of the operation specified `argument` in `assert_object`. The logic does not differentiate if an `argument` is optional or mandatory. All asserts imply: If the `argument` is given, it must pass the `assert`. If the `argument` is not given, assert is implicitly passed.
#### `any` #### `any`
Stateless assert, all argument types. `Argument value` must be equal to one of values in the data list Stateless assert, all argument types. `Argument value` must be equal to one of values in the data list
@ -113,8 +113,11 @@ The assert that needs to pass is now `current_cumsum + incoming value <= max_cum
#### `limit_monthly` #### `limit_monthly`
Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes). Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes).
#### `contains_only` #### `attribute_assert`
Stateless assert, only for dictionary type objects like `options`. The `argument` of the operation is a dictionary type objects and is only allowed to contain the attributes in the data list. Stateless assert, only for dictionary type objects. The `attribute_to_assert` list contains mappings between attributes and asserts that they must fulfill, if present in the dictionary.
Note:
- Assume `asset_update_operation`. All attributes of its `options` must be filled on update call. This assert can not be used to realize a "may only change attribute xzy of `options`". This would require that the logic knows which of the arguments are reflected on-chain and it knows how to query it for every operation that contains `options`. If `options` are to be restricted with this assert, all values that should not change would need be fixated by defining a `any` assert for those attributes, while having e.g. a `lt` assert for the one attribute that is allowed to change.
#### Example: Simple transfer #### Example: Simple transfer
Assume account A and B and some unrelated key K. Furthermore A has a custom active authority in the following way: Assume account A and B and some unrelated key K. Furthermore A has a custom active authority in the following way: