A more intelligent & useful history file & way to query it

[kilasuit]

It would be great to have a much more intelligent & complex history file than the current simple implementation that we currently have, although to achieve this I expect that it would likely be much more computationally expensive than the current implementation.

Ideally I would like to see this be more structured & complex and able to be queried in a way that allows for much better analytics of common command use that enables inspection on the count of use being aliased or using the full command name, common parameter combinations as well as a count of the use of each parameter & arguments to that parameter.

Some loose goals

• Local Sqlite file - Default option
• Remote sqllite or other db format (for cross machine history reasons) - Configurable option
• Configuration options - including continue to use current file for those that want it
• Initial base DB Schema
• User Extensibility of DB Schema
• Additional Querying cmdlets

[lzybkr]

Cross session sharing makes this somewhat hard to implement without a proper database.

I see sqlite might be a reasonable option.

[daxian-dbw]

The suggestion to use Frecency algorithm for history prediction (#1808) and also possibly a local ML model to provide predictions from the history patterns would also require a more powerful storage for history. So yes, we can look into replacing the history file with sqlite.

[kilasuit]

@daxian-dbw This still would be a big win for PSReadline going forward and it would be great if you and I could find some time together to make it happen

[daxian-dbw]

I have been wanting to do this, but it just couldn't get in the priority cut due to the limited team resources.
@StevenBucher98 has put this in the 2.3.0 release consideration, and hopefully we will get commitment for this one.

By the way, the Microsoft.Data.Sqlite package looks a good fit for this work.

[kilasuit]

I realise it's not a smallish bit of work to implement especially the more I think about additional configurability options we may want to add. Let me try and carve out some time properly going forward so that I can be of use here (starting with me actually writing some C# after a long long time saying I want to!)

[StartAutomating]

This looks interesting.

I tackled some of the requests in a proof-of-concept module I made a bit back: https://github.com/StartAutomating/PowerHistory

I'd hope that one of these days, we'd be more willing to accept PowerShell contributions to the PowerShell language.

[claudio-salvio]

... So yes, we can look into replacing the history file with sqlite.

@daxian-dbw
Perhaps it would be better if both persistence mechanisms were available and users could decide which one to use according to their preference or need.

[StartAutomating]

@daxian-dbw Perhaps it would be better if both persistence mechanisms were available and users could decide which one to use according to their preference or need.

Maybe, and this might just be crazy talk here, but maybe one could store persistent history in a vault (rather than reinvent a wheel here)

[kilasuit]

@claudio-salvio This is something that I would look to have as configurable by user with a preference to use the sqlite by default (or other remote db option) but not remove it until a major version if any available module use metrics shows a mass switchover from current implementation.

[kilasuit]

Maybe, and this might just be crazy talk here, but maybe one could store persistent history in a vault (rather than reinvent a wheel here)

I feel that this would be a goal for the longer term but feel that this is loosely captured under configurability options

[lzybkr]

I'd always sort of intended on implementing something here, I'd been thinking about it before this issue was opened.

There are now some options that work across shells. I've been using atuin and it's meeting my needs for now.