Allow a custom key format in jetstream kv store

[codeKrowe]

Would it be possible to configure jetstream store to allow a custom key format instead of this hardcoded one? For example adding a validKeyFormat option to the KeyValueConfig struct. I'm testing some kv stores at the moment and I have keys with @ and : symbols in them and this regex wont allow these keys.

nats.go/kv.go

Line 302 in c75dfd5

validKeyRe = regexp.MustCompile(`\A[-/_=\.a-zA-Z0-9]+\z`)

Thanks!

[ripienaar]

We limit the allowed characterset to maximise compatability both with languages (unicode especially) and with other, future, backends. Lets say we support Acme KV as a backend, and they dont support @ as a character in a key it wont be pluggable for a set of users.

So the current list might be a bit small in terms of allowed chars but we know it should be possible to support most backends.

[ripienaar]

This is probably not super helpful but we did design this so you can wrap it and do codecs, below an example that makes etcd like / based paths rather than our . based ones by encoding/decoding. Perhaps not immediately useful for your case but conceptially this could help you create your own compat layer for whatever you want.

See slash_encoder.go in https://github.com/ripienaar/encodedkv

[codeKrowe]

If the KeyValueConfig was extended to allow a custom key format, by default the system could use the current hardcoded format above to keep maximum compatibility but would allow some extra characters for my use case

[codeKrowe]

This is probably not super helpful but we did design this so you can wrap it and do codecs, below an example that makes etcd like / based paths rather than our . based ones by encoding/decoding. Perhaps not immediately useful for your case but conceptially this could help you create your own compat layer for whatever you want.

See slash_encoder.go in https://github.com/ripienaar/encodedkv

Thanks, will check it out

[kozlovic]

We are actually considering making the @ illegal in subjects since it can be used internally in some cases for routing of messages. So I would advise against relaxing the current regex.