Attribute resolver and failed data connector

Rod Widdowson rdw at steadingsoftware.com
Fri Jul 28 09:59:47 EDT 2017


Taking this as two questions:

> But that 2nd DB connector does "error out" -- presumably since the first connector didn't fail, 
> the 2nd connector's dependency on the attribute returned by the 1st was considered satisfied,
>  but that attribute didn't get a value.
> 
> Expected or a "bug"? 

If I understand correctly I would say that it was as expected.  

Correct operation of the second connector depends on the variable being present.  In the current language there is no way of saying
where the attribute comes from and even if you could it would still be a failure of the second connector.

> the 2nd connector's dependency on the attribute returned the 2nd connector's dependency on the attribute returned by the 1st was
considered satisfied

Now here I'm confused.  You cannot (again in < 3.4) specify a dependency on an attribute returned by a dataconnector.  You have a
dependency on a plugin which is either a dataconnector (all of it) or an attribute.  But again the first DB has done its job, and
unless you say 

> That error causes the resolver to end up without an "Attribute Context", even though the LDAP connector succeeded and pulled in
attributes.
> 
> Expected or a "bug"? 

Right.  So at that point resolution has failed.  Game over.  Again expected (I’d say).   ISRT that there is either something you can
do with fast fail, or a RFI on V4 to make us do so, but for now a static dataconnector as a backstop is your best bet.

R



More information about the users mailing list