search

ytsapras / robonet_site

Django RoboNet operational database.
GNU General Public License v2.0
0 stars 0 forks source link

Obs24 display showing requests with long exposure times #19

Closed rachel3834 closed 7 years ago

rachel3834 commented 7 years ago

The DB display of observation requests submitted in the last 24hrs shows a large number of requests that have very long exposure times. These are being rejected by the scheduler, hence the observation groups have no tracking numbers recorded. However, TAP has been updated to cap the exposure times requested, so these groups should no longer be appearing. Yet the listed groups seem to have recent timestamps.

mpgh commented 7 years ago

Even the earlier behaviour (i.e. requests with long exposure time) were surprising since our full season simulation did not highlight anything like that. Exposure times >300s have occurred but texp>1000s is highly unlikely. Having a view for the full TAP list (i.e. all AC and MO events) might be a good idea. So far, we have avoided that for performance reasons.

mpgh commented 7 years ago

Is there a chance that the exposure time submitted as float but required as int causes the problem?

rachel3834 commented 7 years ago

Yiannis successfully tracked this down to query_db.get_tap_list, where the code looks for the most recent entries to the TAP table. This function wasn't correctly sorting the returned QuerySet into reverse time order, and instead the DB was returning a QuerySet apparently ordered by the size of the entry in the array...meaning the largest exptime ever requested for that object was the one returned.

I've implemented Yiannis' proposed fix: Tap.objects.filter(event=q.pk).order_by('timestamp').reverse()[0]

as well as adding the reverse() term to the selection of single-event-models as well. Queries to the TAP list now return the same output as expected.