Add feature to unlock Timeseries/Scenarios in a database

[danielhuppmann]

When checking out an ixmp.Scenario and not committing or discarding (or running into an error), the run-id is locked in the database instance. We need an elegant way to 'unlock' the run-id.

Follow-up: this should only be available to admins on central/shared database instance?

[danielhuppmann]

A current workaround is to open the underlying database and, in table RUN, set the status column in the row for the id to 1.

[khaeru]

#30 was reported as a duplicate. I left this comment, copied below to consolidate.

Backend API docs, for reference.

Some thoughts:

• The .check_out()/.commit() methods are in TimeSeries, rather than Scenario.
• I've always felt these were a weird hybrid of SQL and git semantics.
  • In SQL, there is nothing like CHECK_OUT, only COMMIT, ROLLBACK, and some others.
    • ixmp lacks anything like ROLLBACK.
  • git checkout modifies or reverts the working tree.
    • In most workflows, it is not needed to call it before modifying files.
    • Often, when used, its meaning is actually closer to SQL ROLLBACK: git checkout -- file.txt rolls back file.txt to its content as of the last commit.
  • Neither includes a notion of locking.
• .check_out() and .commit() actually do THREE things:
  • Manage transactions.
  • Locking.
  • .check_out() raises an exception if .has_solution() is True. (cf. Incorrect semantics in Platform, TimeSeries, Scenario #113 under “Methods in the wrong place”)
• The 'locked' status of a TimeSeries seems to mean 'locked for other users'.
  • ixmp.Platform and base.Backend don't explicitly discuss the (possibly) multi-user nature of Backends.
  • In SQL, if a transaction fails or is rolled back, it is simply not committed, and nothing prevents another set of modifications from starting immediately.

[zikolach]

ixmp lacks anything like ROLLBACK

there is discard_changes method

git checkout modifies or reverts the working tree

It is incorrect comparison, the semantics of checkout in ixmp is locking of scenario version to make changes. More appropriate would be to compare with svn lock.

In general I agree that the logic is complicated and possibly needs to be simplified. But it is incorrect to compare it with database/SQL transaction model as it has to be hidden from end user.

[khaeru]

Unassigned, as this has gone on to the back burner.

[gidden]

Hi all, I am now running into this issue again when trying to launch multiple runs of message.

In my use case, I am strictly cloneing (i.e., read-only copying) a base scenario to launch multiple derivatives (in this case different kinds of climate targets).

Can someone advise on the current preferred pythonic solution for this scenario?

cc @LauWien @OFR-IIASA

[gidden]

This sounds like it should come back to the front burner. We now have multiple user reports around this issue (see slack channel #message_general).

I have made a similar (though not duplicate precisely) issue in #437

[khaeru]

At #437 it was suggested:

The simplest way around this is to place a read-only status on scenario instances. These would not lock the scenario, but also would not allow changes. They would therefore be robust against unexpected system exits.

Something similar was was attempted in iiasa/ixmp_source#334 for #350. We found that a pure-Python fix for the issue was not possible. I was supporting there, but once we lost our Java development capabilities, it stalled, and has not gone further.

so would suggest making this a high priority.

If it is to be high priority, then that Java dev capability must be found so that we have someone with the time and skills to make the necessary changes in ixmp_source.