All exporting data connectors resolved when specific attributes are requested
Basics
Logistics
Basics
Logistics
Description
Maybe not a bug, and there’s some reason for it, but…when you resolve a specific attribute ID, the resolver first resolves all exporting data connectors without any regard for what they produce, and then goes into the more specific logic that limits resolution.
I think we did that because of the exportAll feature? But we pulled that in V5 I think, so this probably could be optimized to check if the exported attributes include one that’s being resolved or not by moving additional checking up into that loop.
Environment
None
Activity
Rod Widdowson July 19, 2024 at 3:29 PM
extended to test to see how many data connectors get resolve and then added some clumsy code to only resolve an exporting dataconnector if
No attributes requestsed
Attributes were requested and this dc exports one of them
Rod Widdowson July 18, 2024 at 4:10 PM
Read the code. We
Resolve all the preRequestedAttributes
(as noted above) resolve All data connectors that export attributes regardless of whether they export attributes we need.
Then resolve all the attributes requested
If no attributes were requested then resolve by name all the AttributeDefinitions we have
resolving an attribute which has already been resolved is a no-op
So if we request one attribute and it is in a data connector then we do a lot of work in (2) we don’t need to do.
I think that (2) becomes
If no attributes were requested then resolve all exporting data connectors
Else if the attributes that that data connector exports is requested then export it
Otherwise skip it.
It may get resolved later a part of the dependencies of another attribute
But before I code this I want to make sure that I know how to unit test it
Rod Widdowson July 5, 2024 at 9:27 AM
Needs analysis but feels like a downright bug (and hence a “do it now” issue).
Maybe not a bug, and there’s some reason for it, but…when you resolve a specific attribute ID, the resolver first resolves all exporting data connectors without any regard for what they produce, and then goes into the more specific logic that limits resolution.
I think we did that because of the exportAll feature? But we pulled that in V5 I think, so this probably could be optimized to check if the exported attributes include one that’s being resolved or not by moving additional checking up into that loop.