'Checkpointing with a task' db file size

began checkpointing with a task as per documentation example 13.1.3.3
running-suites.html

Since the db file is in a non-scrubbed location in the directory tree, that is subject to quota,
i wonder if the db file size grows without limit? or is there some purge mechanism that perhaps keeps the last K checkpoints?

BTW; the checkpointing is very useful.

Suite DBs do grow without limit, and they store other information besides checkpoints too.

You can configure Cylc 8 to symlink workflow run directories to other locations. (At Cylc 7 that is up to you to do, or if you use Rose with Cylc you can configure rose suite-run to do it.)

BTW; the checkpointing is very useful.

I wouldn’t come to rely on it as checkpointing has been removed from Cylc 8 for reasons explained in this post: Proposed removal of scheduler checkpointing capability

(Cylc 8 has a better way of restarting at earlier points in the graph)

is upgrade to 8 advised?

Getting started with Cylc 8 is certainly advised. You might find it already suits your needs even though it is still in the beta release stage.

i can certainly initiate a cylc8 version of the same suite.

during the transition,

is there a best practice for pruning the cylc7 suite db?

in the meantime, i/ll research cylc8 workalike checkpointing.

I haven’t personally heard of one getting so big that it was a problem. Others might be able to advise, but I presume you could use the sqlite3 command line tool to delete loads of entries if necessary. (This probably is something we should document!)

Not much documentation yet, sorry (in progress…). Basically, in Cylc 8 you can cylc trigger --reflow any task in the graph, past or future, and it will flow on as normal from that point. Restart from a state checkpoint recorded in the DB was really only required because Cylc 7 (and earlier) did not have this “reflow” capability.