Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

ExtendedTime entries may duplicate

Description

Within the original extended time code, it was possible for the following situation to occur:

Here is an example from PublishedMetadata database entries:

ASSESSMENTMETADATAID

ASSESSMENTID

LABEL

ENTRY

2694

624

extendedTime3

(null)

2722

624

extendedTime3

2c7f87e6-360a-4383-8dea-b452013bbc69\

1560\

05/17/2016 11:35 am\

05/17/2018 11:35 am\

05/17/2018 11:35 am

AssessmentID and Label should be a unique pair.

This occurred on 11.x based on 7eb73319d75. It also occurred locally on our original extendedTime code.

This is not a good situation. Extended time data is retrieved using the getAssessmentMetaDataByLabel method. As there are two labels for the same AssessmentID it's a toss up on which entry would be retrieved. This can result in odd behavior (entries showing up in the UI, refreshing, and then not being present); this behavior is what was experienced in the original 2.9 implementation.

To resolve this, I've refactored how extendedTime entries are saved.

Activity

Show:

Matthew Jones November 22, 2016 at 8:27 PM

Leonardo Canessa June 16, 2016 at 9:06 AM
Edited

We only noticed it causing extended time issues to not show up in the UI in the original 2.9.3 based version. When I was testing it in 11, I only went so far as to check if a duplicate (null) record was present. It could in theory cause unexplained behavior. The data structures which store this information are HashSet's / HashMaps which If I recall correctly do not allow duplicates. I do not know hibernate well enough to know how it would handle this case.

Extended Time is one thing, among many, which must be refactored within Samigo.

Neal Caidin June 16, 2016 at 8:24 AM

This seems like at least a critical priority issue. How can the use be affected?

Incorporated

Details

Priority

Affects versions

Components

Assignee

Reporter

Labels

Created June 14, 2016 at 9:04 AM
Updated April 17, 2018 at 8:38 AM
Resolved November 22, 2016 at 8:27 PM