how did you get the db key?
Based on Bill's question - how did I get the key - I 're-got' the key - hmmm, it has changed; that would explain things...
blcli ProvisionJob getDBKeyByGroupAndName /Some_Folder Some_job_name
Using the 'new key', the bcli command to clear devices works as expected. So, what appears to be happening:
- while a folder-path & job_name are static, the 'keys' to the endpoints are dynamic
- change a 'job' and it's key changes (looks like it increments)
- which means that you have to get the 'new key' for the modified job if you are adjusting things via BLCLI...
Yes. the ‘id’ is static, but each object is versioned. The db key is the id + version, so you always need to make sure you get the latest version of the key if you are making changes to the object.
Everytime a job is modified and saved somehow in BSA, the VERSION_ID of the object changes. The DBKey of the object = "DBKey:SJobModelKeyImpl:$JOB_ID-$JOB_VERSION_ID-$BL_VALUE_ID"
The job_id and bl_value_id will never change for a give object, but the job_version_id increments every modification, so the DBKey would change. blcli then uses the is_latest_version field in the db to define if the dbkey you are providing is the latest version of the job or not.
Thanks, that's helpful.
Soooo, leads me to new question - if you have N_JOB_Versions - can you set one of them to the 'LATETEST' verison?, i.e.
- roll-back to version 1, then
- roll back to version3, ...
Not really, because there's a whole lot of other dependencies, and there's no supported interface from the GUi or blcli to do this anyway. You'd have to delete the latest version completely to go back I think, but I don't even think that's possible because of all the other dependencies in the db such as property instances and such...
Ok, based on 'testing' it seems that if you use any VERSION number for a JOB KEY it does not matter; the MOST RECENT version will run... Of course, your mileage may vary... (and I am using BSA 8.6)
Thanks for the responses folks!