scripting the resolver with Velocity "Template" attribute defintion
Cantor, Scott
cantor.2 at osu.edu
Wed Feb 15 21:18:59 EST 2017
On 2/15/17, 9:11 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
> I forgot about the SQL case, so I guess it works ok there if you write the SQL for all the inputs so that they are ordered just
> so, and combine in the desired way (and are all guaranteed to produce the same number of values). I guess explicit
> ordering may be possible for some other cases too, like static.
I definitely use SQL into Template, but I don't happen to need more than one Dependency in my case. I can envision doing that, but probably not in a way that works with the current code because I probably would want it to operate on the two Dependency input sets sequentially and not simultaneously as a combined horizontal row of data.
> True. It might be wise to consider the default behavior for the "simple" cases as distinct from the "advanced" multi-value
> cases. For the latter one should maybe have to explicitly pick an output "combining algorithm", be it the current behavior,
> or a full Cartesian set or concatenation or whatever.
Or make it pluggable and just implement what seems currently useful I guess.
> Fwiw, when I initially started to comment on Peter's suggestion, before I got off on the above tangent, I was going to
> comment/ask: "What would it do if the number of values in the inputs is NOT the same?".
It was Chad's original decision and I think he just didn't see the value in complicating it more than already.
-- Scott
More information about the users
mailing list