Provide DataStore method to get Client[] for Task

[GoogleCodeExporter]

This is needed to implement editing task info from the UI.

The AgentClient class requires me to provide a Client in the constructor.  As 
best I can tell to get the Client(s) that support a specific Task I need to use 
ServerClient.getAllClients(), then Client.getTasks() and then search to see 
which Client(s) support the task.  While this is possible in Studio it's ugly 
and slow.

If you do not want to provide this method I'll do it and place it in my 
SJQAPI.jar, but I was actually going to try to not use my own .jar file.

Original issue reported on code.google.com by tom.mira...@gmail.com on 30 Oct 2010 at 6:48

[GoogleCodeExporter]

It's always going to be easier for me to do these queries for you and look up 
the data you need (and always going to be faster to filter in the DB than to 
search through yourself).  So I'll definitely add this for you.  Just keep 
opening tickets any other views/queries you need.

Original comment by de...@battams.ca on 30 Oct 2010 at 7:02

• Changed state: Accepted

[GoogleCodeExporter]

Looking at the JavaDocs again maybe I misinterpreted the need for this.  Can 
you verify that to edit a Task I just use the setter methods in the Task class? 
Do I need to use AgentClient at all?

Original comment by tom.mira...@gmail.com on 30 Oct 2010 at 7:05

[GoogleCodeExporter]

You must send any edits to a Client object back to the task client via 
AgentClient in order for the properties file to be updated and for the task 
queue to update the Client info on the next ping.

But, the other issue is that you do not need this particular method, here's 
why...

A Task, by necessity, must be associated with a Client.  You do not want to 
edit a Task and then apply those changes to _every_ Client that supports the 
task - that's not right.  An HDCOMSKIP task might only require 25 resources on 
Client A (quad core), but require 100 resources on Client B (single core) so 
editing the resources for the HDCOMSKIP task and applying it to all Clients is 
incorrect.

Instead, a user should edit tasks for each Client separately.  We can already 
view clients individually and we can view the tasks for that client.  This is 
where you should be accepting edits for the tasks of each client.  When a task 
is edited for a Client you update the Client object and then send the update to 
that lone Client only via AgentClient.  You must send it via AgentClient so 
that the agent will update its properties file and the task queue will get the 
updates on its next ping of that Client.  If you don't send the update Client 
back to the agent then the edits will be lost.

Hopefully this makes sense to you as much as it does to me? :)

Original comment by de...@battams.ca on 30 Oct 2010 at 7:13

• Changed state: Reviewed

[GoogleCodeExporter]

Thanks for the clarification.  I've raised a few tickets which are probably 
confusing so let me explain the bigger picture.

I want to be able to edit the Tasks from two places: from the "View All 
Clients" menu AND from the "View All Tasks" menu.  I can fairly easily use the 
same Studio code in both places so why not give the user more flexibility?

As you pointed out, in the "View All Clients" menu I can easily associate Tasks 
to Clients.  The problem occurs in the "View All Tasks" menu.  To create that 
menu I first invoke DataStore.getAllRegisteredTaskIds().  From there I need to 
use the TaskID to get a Task so I can display the various pieces of data 
associated with each Task. This is why I think I need a Map that has the TaskID 
as a key and returns the Task itself.  Then the next problem after I have the 
Task is determining which Clients support that Task? 

So starting from a TaskID I need to be able to get a Task and the Clients that 
support the Task.

Original comment by tom.mira...@gmail.com on 31 Oct 2010 at 12:40

[GoogleCodeExporter]

Right, but I'm saying the "View All Tasks" menu shouldn't be there because it 
doesn't really make sense.  Let's pretend it is there...

So a user has configured two task clients, linux and winxp.  The user wants to 
configure COMSKIP on both clients.  So on linux, she configures the properties 
file for the COMSKIP task like this:

task.comskip.exe=/usr/bin/wine
task.comskip.args=/usr/local/wineapps/comskip.exe $SJQ4_LAST_SEGMENT
task.comskip.resources=50

So in this example, the user is running comskip via wine.

On the winxp host, she configures the comskip task like so:

task.comskip.exe=C:/comskip/comskip.exe
task.comskip.args=$SJQ4_LAST_SEGMENT
task.comskip.resources=100

So on this host, she points to the comskip.exe and wants to limit SJQ to only 
running this task by specifying 100 resources req'd.

So now I ask, if you take a COMSKIP Task object and edit it, where are you 
going to save it?  You definitely don't want to send it back to _all_ agents 
that support COMSKIP because you're going to end up pointing one of them to the 
wrong exe and args settings.  So the only way to do this properly is to only 
list tasks by Client and accept edits for a client's specific tasks.

Furthermore, if I did generate the map keyed on task id then you'd be getting 
an array of Task objects for each key because, in this example, asking for all 
Task objects for TaskId COMSKIP is going to return an array of 2 elements.  And 
if you were to look at the client_tasks table you'd see that there are multiple 
rows for each task id.

So, in conclusion, editing task objects outside the context of a client is not 
possible... unless clicking on a task in "View All Tasks" first provides the 
list of Clients that task is defined on and then you pick the client you want 
to edit that task for.  If you do it that way then you have your Task <-> 
Client association and all is good.  If that's what you're doing then fine, but 
is really worth extra effort?  I leave that decision up to you and if you 
decide it is then I'll gladly make the method in DataStore that returns 
Client[] for a taskid:

public Client[] getClientsForTaskId(String taskId)

Let me know what you decide.

Original comment by de...@battams.ca on 31 Oct 2010 at 1:11

[GoogleCodeExporter]

I believe this method is no longer needed.  Marking as WontFix.  If I'm wrong 
then just update the ticket as necessary.

Original comment by de...@battams.ca on 4 Nov 2010 at 1:39

• Changed state: WontFix