AWS Thinkbox Discussion Forums

Deadline 6 database sturcture

Deprecated Deadline 6 Beta Discussion
#1

Hi there,

here’s a question, do you happen to have a description of what is what in your database?

Or at the very least, we’re trying to get the job state from the database directly, what is the proper db, table and column/row to look at?

Thank you!

#2

First, just a disclaimer that this isn’t supported. We make no guarantees that the database structure won’t change in the future, which is why we always recommend using deadlinecommand to get this information. Now, with that out of the way…

When you installed the Deadline 6 Repository, you were asked to specify a database name for your MongoDB database (ie: deadline6db). This is the name of the database that all the Deadline collections will be in. You can run the mongo.exe command line application on the machine the database is on to explore the contents. Once mongo.exe is running, do this to show the database name(s):

show dbs

Then do this to explore a specific database (make sure to specify the name of the deadline 6 database here):

use deadline6db

Then you can run this to view all the Deadline collections:

show collections

The collection that stores the jobs is the “Jobs” collection. Each job will have an _id property that you can use to query for a specific job, and a Stat field that stores the status. Now the status is just an integer:

Unknown = 0
Active = 1
Suspended = 2
Completed = 3
Failed = 4
Pending = 6

Now whether or not an Active job is Queued or Rendering is based on if the RenderingChunks field is > 0.

There are many drivers available for MongoDB so that you can make use of:
docs.mongodb.org/ecosystem/drivers/

Hope this helps. Again, we can’t directly support this, since there is always the possibility that the internal structure will change in the future.

Cheers,

  • Ryan
#3

I understand that and I am aware of the risk. Thank you very much for the code examples, I’ll forward it to the programmers doing the dirty work :slight_smile:

We opted for the direct db access as that seems to be the fastest way to get the data we need.

deadlinecommand is great, but querying it often has proven to be problematic (hangs from time to time) and mainly very, painfully, slow what we need it for.

#4

I should mention that for 6.1, we will be looking at starting a native Python module for direct Deadline access that should allow you to avoid deadlinecommand for a more direct approach.

Cheers,

  • Ryan
#5

Oh man! I’m getting the chills already! :slight_smile: Can’t wait!

Btw: is it going to be native CPython support or IronPython?

#6

It will be native. We’re no longer using the IronPython libraries in Deadline 6.

Cheers,

  • Ryan
#7

It’s only logical, but I’m still crying a little… :cry:

#8

Just thought I’d mention that I’ve opted for a similar approach. As mentioned, deadlinecommand is pretty slow (especially when it needs to be called many times for a given operation), and the output can be inconsistent depending on what type of command is being run. Basically, the amount of overhead and housekeeping necessary to call out and reliably parse its output on a situation-by-situation basis means it isn’t worth the trouble. Obviously there are some things that are still simpler to do using deadlinecommand (job submission, for example), but for a lot of job/task manipulation, data gathering, and housekeeping, an object-oriented layer built on pymongo is much more intuitive.

Privacy | Site terms | Cookie preferences