RFC: Pruning/Maintenance Features

1

I’m working on a couple of pruning/maintenance features and am interested in feedback on what would be most appropriate.

I’ll start by saying that Drafts, by virtue of storing only plain text, does not use a lot of storage space, and generally performs very well even with large data sets. That said, as time goes on it can be useful to have some general cleanup tools to keep things from getting too bulky. Especially things like having to do a clean restore from the cloud to a new device, etc., can become quite time-consuming with a long history of activity.

To that end, I wanted to add a couple of easy maintenance tasks that are totally optional but could be performed by those who want to do a bit of cleanup now and then.

In particular, the two candidate data sets that can grow a lot over time and are not currently easily managed are version histories and action log entries.

What do you think would be appropriate routines to cull these values? I do not plan to offer lots of options, just a few simple ones. These will, of course, be destructive tasks, so require some care if deciding what to offer.

I have some ideas, and will dump them into this thread, but I thought I’d put this out there first and see if anyone had ideas that might be better or different than what I was envisioning.

2 Likes
2

I can seen version histories having more longevity than action logs. In my use case I only consult the latter when debugging - so the console.

I also don’t tend to retrieve previous versions much so I can’t comment on how far back you’d want to go. Though diffing versions of a draft might be an interesting thing.

So - to me - these need to be separate mechanisms. Especially if they were ever to be automatic with an expiry time (eg anything over 30 days goes).

But, yeah, why store indefinitely stuff you’ll not use - only to have the burden of syncing and storing in iCloud?

3

Here’s a few thoughts…

Action Logging

I tend to turn off action logging for anything other than errors. But I think some people likely benefit from say checking a draft that was auto archived or trashed, to see what action was run to do that and perhaps where it was shared to as part of that process.

Other than to archive action log entries older than X, I don’t think I would ever pay much attention to this. Mainly because I set successful actions not to log.

Version History

Version histories I guess covers two areas - drafts and actions/groups.

Draft Versions

For the former, I find the version history very useful, and honestly, because I don’t keep a lot of long term storage in Drafts, I don’t think my version history will ever be an issue. But, I wonder if an option to compress draft versions might be worth considering?

For example, prune drafts created more than 6 months ago, but rather than pruning all versions, maybe all but the oldest version on a particular date?

Another option might be to prune all drafts to only retain the last X number of versions. This could be done by date too.

For example, prune drafts not modified in the last 6 months, but rather than pruning all versions, prune them down to a maximum of X versions.

Action Versions

I use action versions a little, but not a great deal. But I get the feeling that an X number of versions would be a good way to trim them. Irrespective of date. I think actions are less frequently updated than a draft and the content is less likely to change significantly over a wide range of versions.

Being able to go back a version or three and back out changes or compare previous approaches has definite benefits, but I think if you want more than that, working with a full version control system might be a better fit.

Exporting

Having some options to export would be useful - just in case, and just for reference rather than full restore. But I think actions could already cover that for drafts versions; not for actions/groups though or for action logs.

Functionality & Space Utilised

Given the minuscule amount of space these things take up, I wouldn’t lose any sleep over this functionality. Anything as an option would be an improvement. But, I wonder where people’s space is being used up?

I think what might be interesting is to know just how much space Drafts is “using”. It looks to me like the database, preferences, etc. is taking up a little under 50 MB for me. Is that small, medium or large for a Drafts user?

My iCloud Drive folder for Drafts on the other hand is 835 MB. I’d go out on a limb and say that’s on the large side for a Drafts user. It turns out I have ~270 MB of action backups, ~520 MB of drafts backups, and the remaining ~45MB is stuff going in out and through Drafts.

Yes, I do have both sets of backups set to retain "all’ :laughing:

For me, I think Drafts is using almost 0.9 GB - the majority of which is my backups. As a result, I think visibility for users on these areas and some sort of guidance as to where the space is being taken up and the options Drafts could offer to clear these down, or manage these, would be a good way of approaching this rather than just settings. Settings or inbuilt actions would be good, but combining this with some sort of basic assessment for the user would probably help the less technical Drafts users.

Hope that helps.

4

One function I would like is the ability to get rid of empty Drafts with a short history. I often use Drafts to assemble multiple things from my clipboard history together in a specific order and then cut and paste it elsewhere. These then end up in my Drafts list as -- blank -- which is fine, but they could disappear. Of course, if I remembered to use the cut action in Drafts I could solve my own problem. But when you’re using CMD+X/C/V anyway it takes a moment for my brain to engage.

1 Like
5

That one could already be done pretty easily already with a sweeper script, something like:

// find empty drafts
let drafts = Draft.query("/^$/", "all")

// loop over them, looking for ones with <3 versions and delete them
for(let d of drafts) {
    if(d.versions.length < 3) {
        d.isTrashed = true;
        d.update();
    }
}

Also just generally a good tip that you can find empty drafts using a regex search in the draft list of /^$/.

3 Likes
6

I think maybe for now I’ll just leave it up to other to implement by exposing action logs and more properties/methods on versions to scripting. Then you would write your own sweeper scripts to do clean up.

3 Likes
7

I’m with you on that. Transferring snippets of data from one Mac to another (my use case this week) or between Mac and iOS (usually) - where I don’t want to keep the snippet long term - I often use this technique.

An empty draft isn’t something I want beyond, say, half an hour.