Arvados

Story #8647

Updated by Tom Clegg almost 9 years ago

A work unit is a "view model". It corresponds to an Arvados object like a Job or a Pipeline Instance. Its purpose is to provide the information needed by views. As much as possible, we want our views to _not_ know/care exactly which type of object the work unit represents. 

 For example, a dashboard view might show a heterogeneous list of pipeline instances, jobs, and (crunch2) containers. The view code is simple: it says "show progress bar at X%", it doesn't say "if showing a pipeline then add all components' progress and divide by # components". The latter is the kind of code that belongs in the work unit. 

 <pre><code class="ruby"> 
 class Job 
   def work_unit label 
     JobWorkUnit.new(self, label) 
   end 
 end 

 class WorkUnit 
   # This is just an abstract class that documents the WorkUnit interface; a 
   # class can implement the interface without being a subclass of WorkUnit. 
   def label 
     # returns the label that was assigned when creating the work unit 
   end 
   def uuid 
     # returns the arvados UUID of the underlying object 
   end 
   def components 
     # returns an array of component (child) work units 
   end 
 end 

 class ProxyWorkUnit < WorkUnit 
   def initialize proxied, label 
     self.label = label 
     self.proxied = proxied 
   end 
   def label 
     self.label 
   end 
   def uuid 
     self.proxied.uuid 
   end 
 end 

 class JobWorkUnit < ProxyWorkUnit 
   def components 
     n = -1 
     self.proxied.job_tasks.map do |t| 
       n++ 
       t.work_unit("task #{n}") 
     end 
   end 
 end 
 </code></pre>

Back