Delete and Move APIs

[moogar0880]

The purpose of this issue is to expand upon the existing ConfigStore API to add methods for removing and renaming keys in the ConfigStore.

API

Currently there is no mechanism for performing these operations within venom, however, the logic to implement them should be fairly simple. Two new methods should be added to the ConfigStore interface:

func Move(from, to string) error
func Delete(key string)

Both of these methods must be implemented by the Venom type, which is itself a ConfigStore, along with one additional method:

func MoveAndAlias(from, to string) error

This MoveAndAlias method will, just like it sounds, perform a Move and an Alias to ensure that the configuration data is available under the new keyspace, but that any applications using the old name will still be supported.

Additional Considerations

• Delete operations should be considered successful even if the specified key does not exist
• Move should return an error if either the from key does not exist or if data is already stored under the to keyspace.

Note: The addition of the Move and Delete methods to the ConfigStore API is a breaking change and will require a major version bump once merged.

[ilmanzo]

that's an interesting idea. Should "Move" work across multiple levels ? e.g.

Move("foo.bar","foo") 
Move("foo","foo.bar")
Move("foo","foo.bar.baz")

in the latter case, should necessary intermediate sub-levels be created ?

[moogar0880]

Should "Move" work across multiple levels?

That's a good question, and I guess it depends what you mean by "levels". If "levels" of nested maps in the ConfigStore, then yeah I think so, otherwise you'd have to recursively move all of the keys under a root to truly move a config. For instance given a config that looks more or less like this:

{
    "foo": {
        "bar": {
            "baz": "https://example.com",
            "bat": "https://google.com"
        }
    }
}

A Move("foo.bar.baz", "foo") would result in

{
    "foo": "https://example.com"
}

However, if by "levels" you meant ConfigLevels in the heap, then that isn't something that'd I'd actually considered, but I think the answer is also yes. Which means we would effectively have to iterate over all of the config levels in the heap, check to see if the key to move has been set in that level or not and, if it has, then move it to the new key.

in the latter case, should necessary intermediate sub-levels be created ?

Yeah, I think they'd have to be, otherwise we wouldn't be able to traverse the config map properly to do a lookup or future inserts. Luckily setNested should handle that when the value is re-inserted under the new key.