Make the expanded file extension optional
It would be nice to make a config switch for the expanded file extension.
I agree that it's very clear what happens if you see keys like /myprops.json/bla but it also forces me to make a clear choice up front how to organise my repo(s).
If at some point I decide the json file gets to big and I'd like to split it up in smaller pieces, I can never replicate the original keys that where generated, where I might have already various applications depending on a certain structure. Allowing the extension to be optional gives a bit more flexibility.
i.e.
{
"obj1" : {
"key1" : "value1"
},
"obj2" : {
"key2" : "value2"
}
}
Will end up in {
myfile.json/
--/obj1/key1
--/obj2/key2
If my obj1 grows to big, with more nested objects, it might make sense to split it, bit then I end up with:
myfile.json/
--/obj1.json/key1
--/somenewobject.json/anotherkey
--/obj2/key2
Basically having to change all application that depend on the obj1 key.
So it would be nice if I can force the output to be:
myfile/
--/obj1/key1
--/somenewobject/anotherkey
--/obj2/key2
Also with the upcoming features for .properties files it would be nice to be able to switch, without an effect on the generated keys.
With regards to the .properties support, will keys be exported as is, or will there be an option or created folders per . separation in the key?
Yeah, this is a really good suggestion. Thanks!
As for the properties file approach, it creates the Consul Keys verbatim, so there's no ". to subfolder" magic.
This would also make it (almost) compatible with Spring Cloud Consul which expects file contents (not expanded) to be the value and the key to be the file name without the extension.
To truly be compatible with Spring Cloud Consul, you'd also need to capability of adding a "suffix" at the end of the key. It expects a file "my-settings.yaml" to be in consul with /path/to/file/my-settings/data and value is the contents of the file.