Dependency and RDBMS QueryTemplate

[Cantor, Scott]

On 1/19/18, 10:34 AM, "users on behalf of Tom Poage" <users-bounces at shibboleth.net on behalf of tfpoage at ucdavis.edu> wrote:

> To elaborate my particular use case:

Yeah, I have similar kinds of issues related to databases and lookups, so I'm very familiar. I just haven't attacked them in quite that way so far.

> This seems to be where the Velocity conditional comes in. Maybe something like (syntax TBD)?

Yes, basically. And as you say, it doesn't prevent the query from running so it's not a perfect workaround. I suppose one could get crazy even and conditionally generate invalid SQL that maybe the driver might even catch before submitting, but that's probably hard to manage.

> I haven't gone through all variations I can think of yet, but the ANDed actviation condition only seems to be satisfied
> (RDBMS attribute release, cf. aacli.sh) when I also release the queryAttribute in the attribute filter (which I didn't want,
> but may settle for). Of course, this may only reflect my lack of understanding of the sequence of operations during
> attribute resolution.

I don't know where filtering would come in, normally if you're staying inside the "main" execution of the resolver, all that happens pre-filtering. Is this use case a separate run of the resolver in a custom extension or MFA rule or something like that?

Anyway, the upshot is: I think Rod and I agree that the ordering between activation conditions and dependency evaluation is probably "correct" now and should be documented. However, I don't believe that in general you would be able to access the dependency's output inside the activation condition because it's not really available via the ProfileRequestContext.

I would say that's a valid use case, but would need a RFE filed and may or may not be simple to do.

-- Scott