So first up, I love the visual grouping of jobs under BatchNames, it makes my eyes hurt way less than they used to.
Now, I’m currently submitting all relevant jobs with something to the effect of BatchName=“Nice Name (uuid-esque string)” to keep them unique, and avoid inserting new jobs accidentally to an old batch group.
I’m wondering whether or not it’s possible to re-use batch names through some sort of flag or repository setting? Like, let’s say I had 10 users each submitting a batch called “Dailies check-in”, I don’t really care that they use the same name, and would love to see 10 groups in the Monitor as opposed to 1 group with a heap of jobs in it.
It does make sense! But batches aren’t really unique objects at the moment.
The job list computes the grouping at display time, and only uses the string of text provided in the “BatchName” property of the job.
At the moment, having batches with exactly the same name aren’t supported and would require us to abstract the name from some underlying marker. I think I have an issue from awhile back I can add you to.
Update: I found a pretty good argument I made on an internal ticket about this use case. How would you be able to tell the different batches apart? Example (I used spaces/tabs to allow duplicates):
When generating batch names in my scripts, I tend to append the current time and date (or at least the time) as a unique ID. At least it carries some information about when the batch was created…
You could add the user name to the batch to make sure the same batch name from 10 different users creates 10 batches, but then multiple jobs from the same user could end up under the same heading.
Thanks for the input guys, if the grouping is just a visual thing computed at display time, it makes sense that batch names need to be unique.
@eamsler: You make a good point regarding the difficulty of telling batches apart. I’n my specific scenario though, I just don’t really feel the need to tell them apart. Let’s say I’ve got something like this going on:
Personally I would be totally content with knowing that “ah, Dan checked in MyFancyAsset three times this week, and Ed finally rendered that shot. Good for them”, and If I needed more information than that I could probably just have a look at the job metadata like comments and extra-args.
@Bobo: Grouping under user ids is a pretty appealing suggestion, thank you! It means I’ll have to shift from a job-centric to a user-centric mentality, but that seems like something I might be able to do…
