[23.2] Set metadata states on dataset association, not dataset

[mvdbeek]

Fixes an issue that @natefoo reported, where other users could get the dataset state to change to FAILED_METADATA on the source.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

This is a minimal fix, we should also split the states between valid dataset states and valid dataset instance states, and have the state setter dispatch to the correct table if metadata states are being set.

[natefoo]

Thanks!

[natefoo]

Existing servers may want to do something like:

galaxy_main=> SELECT count(*) FROM dataset WHERE state = 'failed_metadata';
 count
-------
  8816
(1 row)

galaxy_main=> SELECT count(*) FROM dataset WHERE job_id IS null AND state = 'failed_metadata';
 count
-------
   377
(1 row)

galaxy_main=> BEGIN;
galaxy_main=> UPDATE dataset AS d SET state = j.state FROM job AS j WHERE d.job_id = j.id AND d.state = 'failed_metadata';
UPDATE 8439
galaxy_main=> UPDATE dataset SET state = 'ok' WHERE state = 'failed_metadata';
UPDATE 377
galaxy_main=> COMMIT; -- i did rollback for now though

[jdavcs]

Existing servers may want to do something like:

galaxy_main=> SELECT count(*) FROM dataset WHERE state = 'failed_metadata';
 count
-------
  8816
(1 row)

galaxy_main=> SELECT count(*) FROM dataset WHERE job_id IS null AND state = 'failed_metadata';
 count
-------
   377
(1 row)

galaxy_main=> BEGIN;
galaxy_main=> UPDATE dataset AS d SET state = j.state FROM job AS j WHERE d.job_id = j.id AND d.state = 'failed_metadata';
UPDATE 8439
galaxy_main=> UPDATE dataset SET state = 'ok' WHERE state = 'failed_metadata';
UPDATE 377
galaxy_main=> COMMIT; -- i did rollback for now though

I think SET d.state (d missing in first UPDATE?)

[natefoo]

UPDATE always works on the table directly following UPDATE afaik. Tried it with the alias and I got this:

galaxy_main=> UPDATE dataset AS d SET d.state = j.state FROM job AS j WHERE d.job_id = j.id AND d.state = 'failed_metadata';
ERROR:  column "d" of relation "dataset" does not exist
LINE 1: UPDATE dataset AS d SET d.state = j.state FROM job AS j WHER...

[jdavcs]

UPDATE always works on the table directly following UPDATE afaik. Tried it with the alias and I got this:

Thanks for checking, I didn't know this!

[nsoranzo]

Late to the party, but I guess that should have been set_metadata_success_state

[mvdbeek]

Oops, fixed in #17481