scripting the resolver with Velocity "Template" attribute defintion

[Brent Putman]

On 2/15/17 8:25 PM, Cantor, Scott wrote:



> So I do think it's totally undefined,

Well, I think *currently* it is defined (although maybe not clearly
enough) and doing what the wiki and Javadocs say, as evidenced by the
language around the same number of values requirement.  Reading the
code, it's pretty clear it's doing what is intended, rightly or wrongly.


>> It's fine if you've got just 1 dependency (with either 1 or many values).  It's also fine if you've got multiple dependencies
>> with 1 value each (or maybe *at most* 1 value each).
> I would imagine it works if you have 5 input attribute definitions that supply material for 5 SourceAttribute expressions and all have the same value count. At least, I would think it might.

By "fine" I meant "makes sense", in a practical way.  It certainly
functions without error in all the cases.  Except for the special case
I mention below, it just doesn't strike me as something one could
typically practically and reliably use in the multi-input+multi-value
case.  


>
>> But the multiple dependencies with multiple values case seems an issue to me.  Say you have dependency d1 with values
>> (foo, bar, baz), and d2 with (x, y, z), with each set of values in that iteration order.  As near as I can tell, the template is
>> going to get executed 3 times, with the following values:
>>
>> (foo, x)
>> (bar, y)
>> (baz, z)
> I think that's the case I allude to above. And I would contend that's sensible if it's what your mental picture happens to be. It makes more sense for AttributeDefs than DataConnectors.
>
>> Since the value ordering is arbitrary, that doesn't seem very useful.
> It's not arbitrary. Attributes are an ordered set of values, very explicitly. We actually broke that pre-3.0 until I caught it and realized what we'd done. The reason of course is modeling SQL result sets out of DataConnectors, maintaining NULL values inside those sets, etc.

Yes, I misspoke. The ordering is not arbitrary in a technical sense. 
But the way the values are combined only makes sense if you know and/or
control the order of *all* the input values. I was trying to convey
that the ordering is often going to be quasi-arbitrary from the *user
standpoint*.

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.

But I don't think that model works for the general case, like LDAP or
others, which produce values in orderings unknown to, and
uncontrollable by, the user.  That was my point, and for that reason it
seems problematic that it does it that way unconditionally and by
default.  It should perhaps only do that via explicit config.


> Thoughts? 
> I think virtually anything might be possible or useful, but once Rod has blown Dependency to the hellpit it belongs in, we have a shot at actually controlling what's actually possible to specify.


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.

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?".   I was
going to say that the only 2 obvious sensible things would be: 1) only
iterate as many times as the smallest number of values.  This would
result in some values not being used. This is what Python zip() does.
2) iterate as many times as the greatest number of values, and use a
null/empty value for cases where a specific input's values are
exhausted.  Neither really seems ideal...  I guess it could also: 3)
cycle on the inputs which are less than greatest number (treat each
input like a cyclical "generator").  But at that point my brain starts
to melt.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170215/2d569b87/attachment.html>