AWS Thinkbox Discussion Forums

documentation

The jobs’ JobinfoFromJob function has no documentation in the public pdfs for 6.2

(Is that the proper way of getting regular job info properties from a job object? Need to find out if the job is a maintenance job or not)

That function is an internal function that isn’t meant for public consumption, which is why it’s not documented.

If you have a job object, you can just check it’s JobMaintenanceJob property to see if it’s a maintenance job or not.

When you have a job object, you have direct access to all it’s properties. Check out the Scripting Reference docs, and look at the Job class:
docs.thinkboxsoftware.com/produc … 1_job.html

Cheers,
Ryan

Thanks Ryan, found it. A bit weird though, that the property name is listed as “JobMaintenanceJob”, but it only works as “MaintenanceJob”

So this works:

jobs = MonitorUtils.GetSelectedJobs()
jobs[0].MaintenanceJob==False

The JobMaintenanceJob property is just a wrapper around the internal MintenanceJob property. We did it this way so that we can change the internal properties and not affect the public ones. We recommend you use the former just in case we need to tweak something in the future.

Cheers,
Ryan

Thanks Ryan, i made sure to use the proper function instead.

A lot of times i find myself using dir(obj) on deadline objects to figure out what my options are. The internal variable names are currently not distinguishable from the external ones. Small suggestion, but maybe using the python standard single underscore as the first letter for internal (private) functions might help with that. So this would become ._MaintenanceJob

Might be a dangerous change at this point (who knows how many scripts out there use the internal names), so just putting it out there… :slight_smile:

Not sure what it is about the documentation, but i find that i can’t really extract the information i need from it… Maybe the Member function list at the top of the pages could omit the one sentence description as its usually redundant anyway (due to the descriptive function/member names), so instead of:

You would just have:

That way you could get a quicker overview of the function/member lists. Right now, you can find the same limited information 4 places:

Click on More… you get this:

A lot of lines for something that’s not more descriptive than the actual function name. Would be nice to have usage examples in the detailed view for example, links to existing scripts using it, default implementation, etc.

All that aside, we have had a pretty good couple of months with 6.2.1. Its been extremely stable, had zero issues. We are almost second guessing switching to 7 in the short term (almost) :slight_smile:

Another thing that’s sometimes confusing is that some properties can be accessed through the main objects (Job, Task etc), but some need to be queried through RepositoryUtils.
The object oriented classes usually lead me to look for the functions first in there. Say, i want all the tasks to a job i already have the object for, i instinctively look for Job.Tasks. But there is no such function / member.
Or for example, the auxiliary folder, it cant be directly queried from Job, but it can be via RepositoryUtils. But i can get the aux filenames from the Job via JobAuxiliarySubmissionFileNames. It seems a bit inconsistent as to where i need to look for functions.

Privacy | Site terms | Cookie preferences