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