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

Make the expanded file extension optional #46

Open
momania opened this issue Feb 1, 2016 · 2 comments
Open

Make the expanded file extension optional #46

momania opened this issue Feb 1, 2016 · 2 comments

Comments

@momania
Copy link

momania commented Feb 1, 2016

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?

@ryanbreen
Copy link
Collaborator

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.

@dnathanson
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants