Workflow Archiving

Archiving methods (a.k.a. "Workflow Archiving")

Why do we have this feature? It's useful to users because our users constantly iterate on their WDLs. At the time of this writing, there's no way to maintain multiple versions of the same WDL without creating a brand new method. This leads to a situation where users' workspaces can become cluttered. Archiving solves this by hiding methods from the user and excluding archived methods from certain queries.

Design and terminology Internally, CBAS uses the term "method" to refer to the representation of a WDL and its associated inputs and outputs. The design doc for this feature is called "workflow archiving" and not "method archiving" because users often refer to the WDL/input/output bundle as a "workflow". (This is an example of terminological confusion that we would ideally resolve somehow, someday.)

"Archiving" is synonymous with a "soft" or "logical" delete: in other words, we do not actually delete any rows from database tables when a user archives a method. Instead, we update the method's "status" field to indicate that the method should be considered "archived".

Method Status: At the time of this writing, there are two statuses, both related to this problem: ARCHIVED and ACTIVE. The method's status field is a String type to leave open the possibility that we would add more statuses, and so that it can follow a similar implementation pattern as statuses for run sets.

Method Versioning plans: We decided against deleting methods from the database entirely because we have plans to build full-fledged method versioning functionality, and we feel that it's worth the minuscule cost in database space to keep our options open. It's important to note that we don't think there are any real auditing implications here, because anyone user with writer permission in the workspace can modify the database at will -- so methods data isn't guaranteed to stick around anyway.