Result set handling bugs
Rod Widdowson
rdw at steadingsoftware.com
Fri Oct 17 04:21:28 EDT 2014
> If this is a major change, so be it, but I don't see that there's a
> choice. Rod, can you enlighten me as to the impact?
I would be astonished if it did, and the fact that you can run the
regression tests supports this. My memory of the core attribute code (which
is pretty much as inherited from Chad) is that it just doesn't care - it’s a
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).
> We have to handle relational data and that means ordered lists so the
indexes line up.
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.
By the way, from a very quick scan of V2 the attribute values there were
held in a Collection, but purely by accident (I assume) the implement basic
implementation happened to use an ArrayList. So this is a good find; of
course what really makes this visible is the move from the hideous (to my
eyes) "attribute.getValues().add()" paradigm that V2 had.
> FWIW, I have a major check in that refactors the IdPAttribute API into
> List<> instead of Set<> and made a number of adjustments to the plugins
> and dependency merging helpers.
I would get it in ASAP. I'll review the change if you wish. In this case
I'd also trust the regression tests - I worked quite hard to make sure we
had good coverage (it was the first V3 task I had). I'd also trust a real
live deployment (I have to assume that you are trying to deploy the OSU
configuration onto V3) more than any regression test.
> I left the filtering API as Set<> to prevent the filter from reintroducing
duplicates.
That makes a lot of sense, again my worry is scripted compatibility but we
now that this is very rare.
Rod
More information about the dev
mailing list