Re: [HTCondor-users] thoughts on HTCondor python bindings submit improvements

[John M Knoeller <johnkn@xxxxxxxxxxx>]

Leaving the transaction is distinct from completing submission.   This is allowed, for instance.

with schedd.transaction as txn :
   sub.queue(txn, 1)
   sub2.queue(txn, 1)

This would be one transaction, but 2 clusters of 1 job each would be submitted.

While the code below looks pretty much the same as the above to the transaction object, but it should submit a single cluster of 2 jobs.

with schedd.transaction as txn :
   sub['args'] = 'first args'
   sub.queue(txn)
   sub['args'] = 'second args'
   sub.queue(txn)

from the perspective of the bindings, that code is not just logically but effectively identical to 

with schedd.transaction as txn : 
   for d in list_of_dcts :
      sub.update(d)
      sub.queue(txn)

-tj

-----Original Message-----
From: HTCondor-users [mailto:htcondor-users-bounces@xxxxxxxxxxx] On Behalf Of Dimitri Maziuk
Sent: Friday, April 27, 2018 1:40 PM
To: htcondor-users@xxxxxxxxxxx
Subject: Re: [HTCondor-users] thoughts on HTCondor python bindings submit improvements

On 04/27/2018 01:15 PM, John M Knoeller wrote:
...

Yeah, I was wrong anyway, I must've been thinking about catching a
GeneratorClose in a coroutine.

Nobody's going to stop us from doing "for foo in itemdata :
sub.queue(txn,(foo,))" anyway. Some sort of commit() would be my choice,
along the lines of

with schedd.transaction() as txn :
    with sub.queue(txn) as q :
        for foo in itemdata :
            q.queue(foo)

with implicit q.commit() on exit from context, or explicit for those who
want it.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu