Operator needs to support other creation methods besides 'request_id'

[stevekm]

Currently, Operator can only be created with a single request_id;

beagle/runner/operator/operator.py

Line 10 in 10af88a

def __init__(self, operator_name, request_id):

However, we need to be able to create an Operator based on other things like multiple request IDs, run IDs, FileMetadata ID's, etc.. Support for Operator creation from Run ID's will be required for Roslin QC Operator for upcoming release. Future support for multiple request_ids will be required in the future, and support for FileMetadata ID's will be the most flexible.

A suggested Operator implementation would look like this:

class Operator(object):
    def __init__(self, operator_name, request_ids = None, run_ids = None, filemetadata_ids = None):

This will allow Operator's to implement methods to build their inputs from any combination of requests, runs, or files.

[stevekm]

Another possible solution would be to not use run_ids but instead pass the actual Run queryset. This would make it a lot simpler. This could also be expanded to support a more generic list of database instances (Run, FileMetadata, Port, etc.), and the Operator would use its own internal logic to use each of them for building pipeline input. Since Run and Port are ultimately just a proxy for FileMetadata, I think that FileMetadata should be the base object that the Operator is designed to work with. This would be supported by moving "output metadata" to the FileMetadata table as per #85 and #121

[sivkovic]

Implemented in 1.1.0:
https://github.com/mskcc/beagle/blob/release/1.1.0/runner/operator/operator.py

[allanbolipata]

Closing.