AttributeValue records with both and Active and Inactive record for the same content
Hi everyone
We've found several AttributeValue records (193 pairs) which have 2 states in the files for the same effectiveTime - one Active and one Inactive.
For example:
id effectivetime active moduleid refsetid referencedcomponentid valueid
34105af2-75df-4851-bb1b-10481862a050 20170131 1 900000000000207008 900000000000490003 2475924014 900000000000495008
402ef83b-0033-5802-b73e-a9d92c98fa48 20170131 0 900000000000207008 900000000000490003 2475924014 900000000000495008
Our first thought was that we can't remove the inactive rows as they have been published, and therefore we shouldn't "change history" and break the RF2 standard.
However, on further consideration the audit trail of what we have published is ambiguous, and so in this particular case it might be better to remove the incorrect rows completely. The reason this wouldn't be contravening the RF2 standard, is because it wouldn't technically be "changing the past", it would instead be making it clear what the past actually was.
Anyway, as always please provide your thoughts!
Kind regards
Andrew
Comments
I don't believe this is a problem...(and why we don't test for it )
The current "inactivation indication" for this description is provided by the first member - 34105af2-75df-4851-bb1b-10481862a050
I approach this with the question - "What would I use this refset for?".
In this case "I want to find the current description indicator for 2475924014?" -
select from refset_snapshot where referencedcomponentId = 2475924014 and active = 1;
For this, the extra row is irrelevant.
Even if my use case is "What was the state of the 2475924014 on 2017-01-31 ?" I'm still only interested in active states.
The only time I'd ever care about the inactive states, is if I were patching my local database, and maybe a "active = 0" triggered a "delete" operation (and "active = 1", triggers "insert")
Which is still fine, because the memberUUID is different. It'd remove the existing entry, and then add a new entry. It's an possibly redundant transaction, but not harm.
We see this pattern everywhere, including the relationship file - where there's around 230 such instances in the stated and it's over 9000 in the inferred! (> 150 thousand to be more accurate).
Have a look at 2514009 as an example.
And a tiny few (5) for the descriptions - though legacy. see: 155008
I'd blame tooling (everyone's) behaviour, but so long as there's only one instance of a componentId on any given effectiveTime, I don't see a problem.
Hi,
Sorry for being late on this, but it is because I am on parental leave.
I started to type an answer, but then realized that @Matt Cordell basically already has written the answer I started to type.
It is not an error and need therefore not be fixed. It is how RF2 works, even if some people might find it irritating.
Regards
Mikael
At first I wondered why our tests didn't pick that up, but it isn't one component with two versions on the same date, the refset memberships have different UUIDs. @Matt Cordell maybe a new rule looking for refset members that are identical other than active status and component UUID?
Depending upon the code people have written the removal of one of these rows could be a clarification or a change. The problem is that the same row removal could be a clarification to some and a change to others. So I think highlighting it is a good thing. One way to do that is to retrospectively change history, which will be no change for some and a change for the better for others (to the correct interpretation).
Anyway I think this is another case for the "negative delta" which makes this explicit and is something that can be used as a machinable trigger to check a change.