Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kdb set user/ and -N user should behave the same, -f for old behavior #2561

Open
markus2330 opened this Issue Mar 29, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@markus2330
Copy link
Contributor

markus2330 commented Mar 29, 2019

@sanssecours Can you maybe help define the behavior here?

@markus2330 markus2330 self-assigned this Mar 29, 2019

@sanssecours

This comment has been minimized.

Copy link
Member

sanssecours commented Mar 29, 2019

If you mean that something like

kdb get user/tests/get

should behave the same as

kdb get -N user /tests/get

, then I think that sounds reasonable. What exactly is the old behavior? As far as I can tell kdb get does not support an argument -N yet:

kdb 2>&1 get -N
#> kdb: invalid option -- N
#> Sorry, I could not process the given options (see errors above)
#> 
#> Usage: kdb get <name>
#> 
#> Get the value of an individual key.
#> When the key starts with / a cascading lookup will be done.
#> 
#> Example:
#> 
#>    kdb get system/elektra/version/constants/KDB_VERSION
#> 
#> -a --all                 Consider all of the keys.
#> -H --help                Show the man page.
#> -n --no-newline          Suppress the newline at the end of the output.
#> -p --profile <name>      Use a different profile for kdb configuration.
#> -v --verbose             Explain what is happening.
#> -V --version             Print version info.
#> -C --color <when>       Print never/auto(default)/always colored output.

.

@markus2330 markus2330 changed the title kdb get user/ and -N user should behave the same, -f for old behavior kdb set user/ and -N user should behave the same, -f for old behavior Mar 30, 2019

@markus2330

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Mar 30, 2019

If you mean that something like

exactly, but I meant kdb set

What exactly is the old behavior?

That one way supports the validation and the other does not.

@sanssecours

This comment has been minimized.

Copy link
Member

sanssecours commented Mar 31, 2019

That one way supports the validation and the other does not.

Yes, it make sense that in the following situation:

kdb mount tutorial.dump /tests/spec dump validation
kdb setmeta spec/tests/spec/test check/validation '[1-9][0-9]*'
kdb setmeta spec/tests/spec/test check/validation/match LINE
kdb setmeta spec/tests/spec/test check/validation/message 'Not a number'

, the command

kdb set user/tests/spec/test 'incorrect value'

fails, just as

kdb set -N user /tests/spec/test 'incorrect value'

and

kdb set /tests/spec/test 'incorrect value'

do. Using the option -f (force) to change the value, even if the validation fails sounds like a good choice.

@markus2330

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Mar 31, 2019

Exactly! Thank you for the description of the behavior. Maybe we should also add -N to kdb get so that the same syntax can be used for every kdb command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.