Closed DamianEdwards closed 1 week ago
@davidebbo can you look at this one?
This has some overlap with #4429. e.g. the first overload there is the same as the first from Suggestion 1 here. But the rest is distinct. How do we rationalize this? We sort of want the union of both proposals?
See also my comment there, as the same questions apply here. In particular, the 'Do not add multiple overloads with optional parameters' is going to hit us. Suggestion 2 probably avoids it.
Other question: why have distinct overloads for GenerateParameterDefault
and ParameterDefault
. Given that the former extends the latter, isn't the latter one sufficient?
Other question: why have distinct overloads for GenerateParameterDefault and ParameterDefault. Given that the former extends the latter, isn't the latter one sufficient?
The feature that saves generated values to the user secrets store relies on GenerateParameterDefault
so I went with a concrete overload to enable that. We could just downcast instead though.
@DamianEdwards and to be clear, everything you're discussing here is a fallback value, right? i.e. if the setting is found in app settings, we use that as normal. Otherwise, we use this, instead of not having a value at all.
That seems like a very simple change, and I'll take a crack at it.
I like Solution 1 better. And I think the 'Do not add multiple overloads with optional parameters' warning it gives is bogus in this case, since all the overloads are well differentiated by param types.
The manifest implications are interesting. My take is:
ParameterDefault
overload, it will end up in the manifest. At least for GenerateParameterDefault
, we know that generates a valid schema. Alternate ParameterDefault
implementations are probably hard to support right now without schema changes.string defaultValue
overload, it probably shouldn't generate anything at all. Looking at https://json.schemastore.org/aspire-8.0.json, generate
seems like the only valid value for default
. This matches what @davidfowl says in #4429 about "Adding a parameter with a default value only used at runtime"Ok, PR #5529 is out. Let's start with that before digging into #4429, which has more open questions.
Background and Motivation
Adding parameters to the application model via
builder.AddParameter("name")
is straightforward enough, but sometimes it's desirable to create parameters that have a default value generated via theGenerateParameterDefault
type, or use a hard-coded default value string, or customParameterDefault
implementation. This is difficult to do today asParameterResource
default behaviors are largely controlled by the body of thebuilder.AddParameter()
method itself and that method accepts no overloads for controlling parameter default values.There should be API that makes it simple to set a parameter's default value in the same way that the implicit password parameters for many resources are.
Related:
4429
3679
Proposed API
Suggestion 1: Overloads of
AddParameter
that acceptstring,
GenerateParameterDefault
, andParameterDefault
.The second overload above (the one that accepts
GenerateParameterDefault
would create theParameterResource
internally using theCreateGeneratedParameter
method which ensures the generated value is stored in user secrets automatically.Suggestion 2: Extension method to
IResourceBuilder<ParameterResource>
that allows setting the parameter default valueAn alternative approach is to add new extension methods that enable setting the default value after the parameter is created and added to the application model with
AddParameter
:The second overload above (the one that accepts
GenerateParameterDefault
would wrap it in an instance of theUserSecretsParameterDefault
internal class which ensures the generated value is stored in user secrets automatically.Note that this approach would likely require some reworking of how
AddParameter
is currently implemented as it currently defaults the parameter resource initial state to an error if a value isn't found in configuration.Usage Examples
Suggestion 2:
AddParameter
overloadsSuggestion 2:
WithDefault