# [some] validate_drp derived metric values visualization is mangled in dashboard

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Epic Link:
• Team:
SQuaRE

#### Description

A few metrics (eg, AD1, PA2) as being rendered in the qa-dashboard has having multiple values per dataset run. This might be an issue with the format being submitted by post-qa or it may be internal to the dashboard (or both).

#### Activity

Hide
Michael Wood-Vasey added a comment -

At the JTM Angelo Fausti and I discussed this and agreed that the dashboard should just show the minimum threshold values.

Show
Michael Wood-Vasey added a comment - At the JTM Angelo Fausti and I discussed this and agreed that the dashboard should just show the minimum threshold values.
Hide
Michael Wood-Vasey added a comment -

Another really quick partial fix is to just not draw lines between points.

Show
Michael Wood-Vasey added a comment - Another really quick partial fix is to just not draw lines between points.
Hide
Angelo Fausti added a comment - - edited

More info on this issue.

If we look at the data returned by the measurements API we see the three values for AD1, for instance

https://squash.lsst.codes/dashboard/api/measurements/?job__ci_dataset=cfht&metric=AD1

what's missing there is the spec level each measurement of AD1 corresponds to.

That information is indeed available as measurement metadata (see the spec_name key)

https://squash.lsst.codes/dashboard/api/jobs/?search=842

I think I just need to include the spec_name as part of the data returned by the measurements API, then we can distinguish the measurements and draw a different line for each spec level.

If spec_name == None then there is no need to distinguish between the measurements and we draw just one line.

That would completely solve the display problem.

Show
Angelo Fausti added a comment - - edited More info on this issue. If we look at the data returned by the measurements API we see the three values for AD1, for instance https://squash.lsst.codes/dashboard/api/measurements/?job__ci_dataset=cfht&metric=AD1 what's missing there is the spec level each measurement of AD1 corresponds to. That information is indeed available as measurement metadata (see the spec_name key) https://squash.lsst.codes/dashboard/api/jobs/?search=842 I think I just need to include the spec_name as part of the data returned by the measurements API, then we can distinguish the measurements and draw a different line for each spec level. If spec_name == None then there is no need to distinguish between the measurements and we draw just one line. That would completely solve the display problem.
Hide
Angelo Fausti added a comment - - edited

An update on this issue:

spec_name is part of the measurement metadata which is stored in a JSONField in the measurements table. mariadb does not suport filtering on this datatype and it turns out that it's quite inefficient to extract this value from the field and test it in order to filter out the measurement, specially because most of the metrics have 'spec_name': None

However we need a solution for that, in lsst.verify metrics can be tagged and we want to filter efficiently by tag, e.g. the filter in which the measurement was done.

Show
Angelo Fausti added a comment - - edited An update on this issue: spec_name is part of the measurement metadata which is stored in a JSONField in the measurements table. mariadb does not suport filtering on this datatype and it turns out that it's quite inefficient to extract this value from the field and test it in order to filter out the measurement, specially because most of the metrics have 'spec_name': None However we need a solution for that, in lsst.verify metrics can be tagged and we want to filter efficiently by tag, e.g. the filter in which the measurement was done.
Hide
Angelo Fausti added a comment -

In the current implementation it is kind of painful to make this change. In order to make more efficient queries, we have to add the new field spec_name in the Measurements table change the serializer to parse that information and save to the spec_name field and we have to make this change for all the data already ingested in the database (probably we cannot extreact the spec_name value with SQL alone)

Show
Angelo Fausti added a comment - In the current implementation it is kind of painful to make this change. In order to make more efficient queries, we have to add the new field spec_name in the Measurements table change the serializer to parse that information and save to the spec_name field and we have to make this change for all the data already ingested in the database (probably we cannot extreact the spec_name value with SQL alone)
Hide
Angelo Fausti added a comment - - edited

I've started SQuaSH implementation with Mariab DB 10.1, it looks like in 10.2 it's possible to query a JSON field

https://mariadb.com/resources/blog/json-mariadb-102

see also

https://mariadb.com/kb/en/library/json-functions/

for all the json functions available.

Have to figure out the status of

http://django-mysql.readthedocs.io

in supporting these features. If we manage to use them it will certainly alleviate the problem.

Show
Angelo Fausti added a comment - - edited I've started SQuaSH implementation with Mariab DB 10.1, it looks like in 10.2 it's possible to query a JSON field https://mariadb.com/resources/blog/json-mariadb-102 see also https://mariadb.com/kb/en/library/json-functions/ for all the json functions available. Have to figure out the status of http://django-mysql.readthedocs.io in supporting these features. If we manage to use them it will certainly alleviate the problem.
Hide
Angelo Fausti added a comment -

Reviewing back log tickets, this issue was fixed when we redesigned the SQuaSH API in DM-12194.

Show
Angelo Fausti added a comment - Reviewing back log tickets, this issue was fixed when we redesigned the SQuaSH API in DM-12194 .

#### People

Assignee:
Angelo Fausti
Reporter:
Joshua Hoblitt
Watchers:
Angelo Fausti, Jonathan Sick, Joshua Hoblitt, Michael Wood-Vasey, Simon Krughoff
Votes:
0 Vote for this issue
Watchers:
5 Start watching this issue

#### Dates

Created:
Updated:
Resolved:

#### Jenkins

No builds found.