Allow for alternative Prefix Trimming order

[spencerr]

The current implementation of prefix trimming is backed by a SortedSet, removing the ability to trim prefixes in a specific order specified by the user.

I currently use a single App Configuration instance to serve configurations for multiple applications. The UI experience is not the best for displaying groups configurations by Label, so I utilize a prefix of {app-name}/ or shared/ and such to group these configurations and display in the hierarchy view. The downfall of this is when I need to trim the prefixes for when an app specifically overrides one of the shared values, I am unable to because of the automatic ordering of the SortedSet.

[zhiyuanliang-ms]

Hi, @spencerr
IMO, label should be used for the scenario that you have different sets of configuration for different applications. Label should be used to group configurations.

The downfall of this is when I need to trim the prefixes for when an app specifically overrides one of the shared values, I am unable to because of the automatic ordering of the SortedSet.

I am digesting the issue. Does the following scenario match your issue?

You have App/Key1, Shared/Key1 and App/Key2 you want your App to use the value of App/Key1 and App/Key2. However, the Shared/Key1 will override the App/Key1 if you trimed the prefixes because "Shared/" place after "App/" in order.

The UI experience is not the best for displaying groups configurations by Label

May I ask what pain point you are experiencing now when you are using our Portal UI? If we are willing to make some improvement to portal UI, would you like to use label to group configuration?

Do you want to display all keyvalues with different labels at the same time, but they are all grouped by labels (rather than being sortied by key name)?

Something like:

- key1 `LabelA`
- key2 `LabelA`
...
- key1 `LabelB`
- key2 `LabelB`
...

Instead of

- key1 `LabelA`
- key1 `LabelB`
...
- key2 `LabelA`
- key2 `LabelB`
...

[spencerr]

Thanks for the reply @zhiyuanliang-ms

Yes, your scenario matches what I am describing.

In our setup, we have various "groups" of variables that we may share between applications. Think items like redis connection information, application urls, etc. We'd like centralize configurations in a single place so we are not duplicating these values across different app configuration instances per application, and to opt-in or control the shared variables an application is given.

Another additional limitation we run into is snapshots having a limit of 3 filters that can be applied. Right now I filter for the {app-name}/*, and shared/* and accept that all shared configurations will be retrieved, were as we'd like to be more granular with the items being pulled in and to be able to use the snapshots.

As far as UI experience, updating the hierarchy view to be able to group by Label and/or separator would be beneficial.

[zhiyuanliang-ms]

Hi, @spencerr

Here is the screenshot of my app config store

By adjusting the order of the Select call, you can specify the order how the keyvalue with different prefix will be loaded. Will this solve your problem?

[zhiyuanliang-ms]

BTW, my previous comment is wrong.

IMO, label should be used for the scenario that you have different sets of configuration for different applications. Label should be used to group configurations.

According to the best practice, using different prefixs (as different namespaces) to group key-values is correct. (My previous comment is wrong. Sorry for the mistake.)

@spencerr

[amerjusupovic]

As far as UI experience, updating the hierarchy view to be able to group by Label and/or separator would be beneficial.

@spencerr Does the option to filter by label on the configuration explorer page work for your scenario or did you mean something different?

[spencerr]

@zhiyuanliang-ms
The ordered select does seem to work, however it does not work with snapshots unfortunately.

@amerjusupovic Filter by the label could work, grouping things does make things a bit easier to visualize. Best practices does seem to mention prefixes being used for separating variables per application however.

[zhiyuanliang-ms]

Hi, @spencerr

The ordered select does seem to work, however it does not work with snapshots unfortunately.

Could you try to create two snapshots for each prefix like this:

Instead of having one snapshot which used two key(prefix) filters like this:

[samsadsam]

Hey @spencerr hope your day is going well. I will recap the issue here and will take as an example this store:

This store has 2 snapshots.

• app1 snapshot contains app1/key1 kv item
• shared snapshot contains shared/key1 kv item

You mentioned that you were unable to override some shared settings with a specific app settings. For a scenario like that, the recommendation is to have your Select/SelectSnapshot statements in this order:

builder.AddAzureAppConfiguration(options =>
{
    options.Connect(...)
           .Select("shared/*") //select shared settings first and app specifc settings next
           .Select("app1/*")
           .TrimKeyPrefix("shared/")
           .TrimKeyPrefix("app1/");
});

In this way, common keys in the shared config will always be overwritten by your specific app settings.

Finally, if you try the snippet of code below, the output would be val=app1/key1 as you wanted. The app1 setting key1 overrides the shared setting key 1.

static void Main(string[] args)
{
    var builder = new ConfigurationBuilder();

    builder.AddAzureAppConfiguration(options =>
    {
        options.Connect(Environment.GetEnvironmentVariable("AAC_CONNECTION_STRING"))
               .SelectSnapshot("shared")
               .SelectSnapshot("app1")
               .TrimKeyPrefix("shared/")
               .TrimKeyPrefix("app1/");
    });

    var config = builder.Build();

    Console.WriteLine(config["key1"]); // outputs "val=app1/key1"
}

In summary, it is the order of Select that matters in your scenario.

I will close this issue. Please re-open it if you have any extra questions/comments/concerns 😃