Chicken vs Egg: Tokens and Collections #213
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
orinoco/dump-things-service#213
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I am exploring the new admin API. It is not intuitively clear what should be created first: a token or a collection. Both want information on the respective other entity.
In the previous file-based configuration approach both types of information were given at the same time. The documentation appears to be silent about a file-less initialization.
I confirmed that I cannot create a token without a collection, and that I cannot create a collection without a token.
The correct order is to create the collections before tokens. Token names are not validated during collection creation, but collection names are validated during token-creation (there is a note in the description of the token-creation endpoint, i.e.,
POST /tokens, inREADME.md, but it is completely lost in the amount of information. The documentation needs to be improved and moved out ofREADME.md).I
@mih wrote in orinoco/dump-things-server#213 (comment):
It should be possible to create collections that reference tokens that do not yet exist (the test setup does so). There might have been another issue that prevented the collection from being created.
Trying to create a token for a non-existent collection will fail.
Maybe. It is, however, not at all obvious that a token can be "imaginary", and one can thereby have invalid configurations.
I think the documentation needs to be revisited from the POV of the current behavior. It is all about configuration files, and those are, at the same time, a lot less relevant now.