A lot of methods in lmfdb.backend.database include a commit parameter. The intention was that you could try something with commit=False and check that it looked okay before actually making changes. But if you use commit=False there isn't much output that would tell you whether your attempt would succeed, and there is very little testing to make sure that commit=False actually has no effect on the database (in particular, some later commands you execute might accidentally commit earlier changes).
I think that the commit=False flag shouldn't be supported by providing keyword arguments everywhere. Instead, if you really want this feature, you can use a DelayCommit context. Removing all the keyword arguments will simplify the code.
Ported from LMFDB's #3524:
A lot of methods in
lmfdb.backend.databaseinclude acommitparameter. The intention was that you could try something withcommit=Falseand check that it looked okay before actually making changes. But if you usecommit=Falsethere isn't much output that would tell you whether your attempt would succeed, and there is very little testing to make sure thatcommit=Falseactually has no effect on the database (in particular, some later commands you execute might accidentally commit earlier changes).I think that the
commit=Falseflag shouldn't be supported by providing keyword arguments everywhere. Instead, if you really want this feature, you can use aDelayCommitcontext. Removing all the keyword arguments will simplify the code.