Like somehow define the config for the generic sol...
# announcements
b
Like somehow define the config for the generic solid, not for the aliased names?
p
hmm…. you might be able to do this with config mapping if you had all the aliases wrapped in a composite solid
a
Hmmm or maybe default values in the defined config?
b
What I'm trying to do is, within a composite solid, I basically want to generate the same child solid N times. The config/inputs to these child solids are all the same each time except I need to change one value (a prefix to an s3 bucket). What I was trying to do is dynamically pass in the prefix param as an input, but I'm actually getting another error because it says the solid needs either an output from a previous solid or an input to the composite (I cannot dynamically generate the input param within the composite solid). What do you guys recommend is the best approach to accomplish what I'm trying to do? I hope that makes sense, thanks again for the help.
a
Hmmmmmmm if you make the prefix a config of the solid you should be able to use config mapping to set the prefix for all the inner solids
If you send over a code sample in a gist or something I could try to modify it to show what I mean ( tomorrow probably )
b
Ok I think I have an idea what you mean. I’ll try that and if I’m still running into issues will send over a gist tomorrow. Thanks again man!
Hey so I think I ran into an issue with the config mapping. It seems that the system wants me to either provide all config through the mapping, or none of it—does that make sense? It's impractical for me to map all my config for this compute_solid via the function so I'm not sure if that solution makes sense for me.
I'll try to put together a gist of what I'm trying to do
a
ya - you’ll need to set the
config
field on the composite with the additional config you want to thread to your solids and then take care of forwarding it in the mapping function