Bug #3586

[API] Job "priority" field defaults to "null", should default to "0"

Added by Peter Amstutz about 7 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Start date:
08/28/2014
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

The "priority" field is used to sort the job queue, and it defaults to null. Unfortunately, the database automatically puts "null" values first in the sorting order, preventing priority from working as intended. The API server should assign a default numeric priority of 0 when creating the model and a NOT NULL constraint should be added to the schema.


Subtasks

Task #3749: Review 3586-job-priorityResolvedPeter Amstutz

Task #3748: Add migrationResolvedPeter Amstutz

Associated revisions

Revision 7f3ed5e2
Added by Peter Amstutz about 7 years ago

Merge branch 'master' into 3586-job-priority closes #3586

Revision d97be42e
Added by Peter Amstutz about 7 years ago

Merge branch '3586-job-priority' closes #3586

History

#1 Updated by Peter Amstutz about 7 years ago

  • Subject changed from Job "priority" field defaults to "null", should default to "0" to [API] Job "priority" field defaults to "null", should default to "0"
  • Description updated (diff)
  • Category set to API

#2 Updated by Peter Amstutz about 7 years ago

  • Target version deleted (2014-08-27 Sprint)

#3 Updated by Tom Clegg about 7 years ago

  • Target version set to Arvados Future Sprints

#4 Updated by Tom Clegg about 7 years ago

  • Story points set to 0.5

#5 Updated by Ward Vandewege about 7 years ago

  • Target version changed from Arvados Future Sprints to 2014-09-17 sprint

#6 Updated by Tom Clegg about 7 years ago

  • Assigned To set to Peter Amstutz

#7 Updated by Peter Amstutz about 7 years ago

  • Status changed from New to In Progress

#8 Updated by Tom Clegg about 7 years ago

This index seems to have been removed from structure.sql in 80cbf4d9, not sure why/how:

-- Name: pipeline_instance_owner_uuid_name_unique; Type: INDEX; Schema: public; Owner: -; Tablespace: 
--

CREATE UNIQUE INDEX pipeline_instance_owner_uuid_name_unique ON pipeline_instances USING btree (owner_uuid, name);

--

It comes back automatically if I do rake db:migrate.

Other than that, LGTM. Thanks.

#9 Updated by Tom Clegg about 7 years ago

Ah, I get it (I think): the jobs_owner_uuid_name_unique and pipeline_instance_owner_uuid_name_unique indices stayed in db/structure.sql in the 3036 merge, even though they had been removed from the migration.

I've fixed my own database, so now it agrees with the migrations instead of agreeing with db/structure.sql. Now we just have to remove those two db/structure.sql entries so it agrees with the migrations. (Perhaps best to do it in a separate commit with refs #3036?)

#10 Updated by Peter Amstutz about 7 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF