Result set handling bugs

[Cantor, Scott]

On 10/17/14, 4:21 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>bucket of values Just like V2 (see below)
>
>My only real concern is scripted attributes - but if the thing was a list
>in
>V2 we should be guaranteeing the same behaviours.  Also and possibly by
>accident I see that the ScriptedIdPAttribute uses the same default type
>(ArrayList) as V2 (see below).

I do have scripts, so I'll get at least some coverage.

>I'll buy this, but I'd like to understand why? I'm trying to see why the
>values are not just a bucket of stuff once we have got them from the
>connectors. Is this for the template handler for instance in which the
>order
>would matter, or does SAML require the ordering?  The template handling is
>certainly a good enough reason.

I was going to write up my use case, so I guess I can just do that. The
short answer is I guess that it's the Template definition more than any
other. Maybe that's the only case (plus scripts).

I build entitlements out of records in our SIS for course enrollment. So I
select that table with the connector and it generates 6-7 attributes out
of the fields. Many of those fields have duplicate values (subject, term).

Then I have to plug that into the Template definition to build a URN for
each record. If you collapse duplicates, that doesn't work.

The practical issue is that we should have made data connectors produce
something other than IdPAttribute that actually modeled relational result
sets. If we're not allowing direct encoding of IdPAttributes produced by a
data connector, we didn't need to make them IdPAttributes, basically.

Having made that mistake (way back in V2), we have to maintain coherent
views of the results at least across simple cases. Once you start mixing
dependencies, things won't stay coherent anyway.

My biggest review need is the PluginDependencySupport thing, because I
just slammed the refactor into that class.

We also need to carefully compare old and new plugins. I'm pretty sure I
hit other regressions, such as the Regex definition not producing multiple
values (I fixed that also).

-- Scott