[Use Cases] Add use cases for mounting #4773
Conversation
| - The given data source is not supported by Elektra. (e.g. wrong file format, syntax errors) | ||
| - Elektra reports the error to the administrators. |
There was a problem hiding this comment.
Why isn't this an error scenario?
| - The opening of the data source failed. | ||
| - Elektra reports the error to the administrators. |
There was a problem hiding this comment.
Please describe what "opening of the data source failed" means. I don't think this is done during mounting except for the --strategy described by me above.
| - The administrators use Elektra to query a list with all current mountpoints. | ||
| - Elektra returns the list with the mountpoints and the data source identifiers. (e.g. filename and path, data source name) | ||
| - The administrators mount a new data source. (see [Use Case: Mount a data source](./UC_mount.md)) | ||
| - The administrators use Elektra to query a list with all current mountpoints. | ||
| - The new mountpoint is now added to the list. | ||
| - The administrators unmount the previously mounted data source. (see [Use Case: Unmount a data source](./UC_unmount.md)) | ||
| - The administrators use Elektra to query a list with all current mountpoints. | ||
| - The mountpoint for the unmounted data source is now not included in the list. |
There was a problem hiding this comment.
The other use cases already cover mounting/umounting:
| - The administrators use Elektra to query a list with all current mountpoints. | |
| - Elektra returns the list with the mountpoints and the data source identifiers. (e.g. filename and path, data source name) | |
| - The administrators mount a new data source. (see [Use Case: Mount a data source](./UC_mount.md)) | |
| - The administrators use Elektra to query a list with all current mountpoints. | |
| - The new mountpoint is now added to the list. | |
| - The administrators unmount the previously mounted data source. (see [Use Case: Unmount a data source](./UC_unmount.md)) | |
| - The administrators use Elektra to query a list with all current mountpoints. | |
| - The mountpoint for the unmounted data source is now not included in the list. | |
| - The administrators use Elektra to query a list of all current mountpoints. |
| @@ -0,0 +1,40 @@ | |||
| # Use Case: List all configuration keys and values from all currently mounted data sources | |||
There was a problem hiding this comment.
I don't know which functionality this is? Is this export? Why does it belong to the mounting use cases?
| @@ -0,0 +1,52 @@ | |||
| # Use Case: Delete configuration data from a file | |||
There was a problem hiding this comment.
I would simplify this and only have a get and set use case. (Delete is part of set).
I think it is enough that you only write the rdb use cases.
I don't think they should be part of mount, but rather another folder ("rdb").
doc/usecases/mount/UC_edit_rdb.md
Outdated
| - The requested key is not found in the database. | ||
| - Elektra reports the error to the administrators. |
There was a problem hiding this comment.
As Elektra simply set whatever is given, the non-presence of keys shouldn't matter (they get created/deleted as demanded).
There was a problem hiding this comment.
Thank you for the remark! I changed the scenario.
There was a problem hiding this comment.
I haven't had time to read all the texts, but from the titles and briefs, I'd say only these three use cases are use cases for mounting: UC_mount.md, UC_unmount.md and UC_list_mountpoints.md
The rest are use cases for file-based backends and database backends respectively. If we want to keep them I'd move them into separate folders. However, I'm not sure we need those at all.
IMO it would be enough to have a UC_mount_file.md and UC_mount_rdb.md in addition to UC_mount.md. UC_mount.md describes mounting in general, and the other two describe mounting configuration files and relational databases respectively. Then all the edit/read/write/delete stuff should automatically follow as a combination of UC_mount_file.md and UC_mount_rdb.md and the general KDB use cases in doc/usecases/kdb.
Only if there are specific difference between file-based and database backends that go beyond technical limitations (e.g. files must be written as a whole, databases could modify individual values), would I create separate use cases. The technical limitations are only relevant on the decision level IMO, but not the more general use case level.
doc/usecases/mount/UC_edit_rdb.md
Outdated
| - The requested key is not found in the database. | ||
| - Elektra reports the error to the administrators. |
There was a problem hiding this comment.
Thank you for the remark! I changed the scenario.
Co-authored-by: Markus Raab <markus2330@users.noreply.github.com> Co-authored-by: Klemens Böswirth <23529132+kodebach@users.noreply.github.com>
Basics
(added as entry in
doc/news/_preparation_next_release.mdwhichcontains
_(my name)_)Please always add something to the release notes.
(first line should have
module: short statementsyntax)close #X, are in the commit messages.doc/news/_preparation_next_release.mdscripts/dev/reformat-allChecklist
(not in the PR description)
Review
Labels