Remove per-property "inheritance" from cached objects #403
Labels
2.1.0-CSD.1
Will be fixed in SARIF v2.1.0 CSD.1.
design-improvement
impact-breaks-consumers
impact-breaks-producers
merged
Changes merged into provisional draft.
resolved-fixed
Addresses and logical locations have a parenting mechanism to provide for caching. Adding a second caching mechanism for these creates unnecessary complexity for consumers that doesn't provide clear value. If producers provide an index, they can recapitulate duplicative properties for purposes of readability but they must remain in sync with the run level version. And so we should remove index.
Even after removing
logicalLocation.index
andaddress.index
, the complexity we refer to still applies to the other cached objectsthreadFlowLocation
,webRequest
, andwebResponse
.Part of the problem is that we have never clearly distinguished between two concepts; we have used the term "caching" to refer to both:
Reuse: Multiple "local objects," for example multiple
threadFlowLocation
objects inresult.codeFlows[0].threadFlows
can reuse the same "cached object inrun.threadFlowLocations
by specifying theirthreadFlowLocation.index
property.Inheritance: Those "local objects" can inherit some properties from the "cached object", while at the same time specifying other properties locally.
It is the inheritance part that really complicates the SDK. Therefore, we propose to remove the inheritance mechanism. For the remaining cached objects
threadFlowLocation
,webRequest
, andwebResponse
, we propose to require that either theindex
property or a set of local properties, but not both, be present.UPDATE @lgolding 4/29/2019: We are restoring the
index
property onaddress
andlogicalLocation
. So this is no longer a schema change (although it is still breaking).The text was updated successfully, but these errors were encountered: