feature: hard delete by tag operation

[yss14]

As already outlined in #71, in my opinion the current naming of the deleteByTag operation is a bit misleading, since it doesn't hard delete cache entries by tag matching, but rather expires them. That's why I included a commit in this PR renaming the current deleteByTag operation to expireByTag to be compliant with the naming of the key based operations.
I'm aware that this means a breaking change in the API and I'm open to discuss how to resolve this if a major release is to avoid.

The main concern of this PR is the implementation of a new operation deleteByTag, which performs a "kind of" hard delete via a lazy deletion logic via invalidation timestamps similar to the approach of the expireByTag (previously deleteByTag) operation.
Here I'm also open to discuss the best approach for the hard deletion logic.

[changeset-bot]

⚠️ No Changeset found

Latest commit: ca18d09

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[yss14]

Not super happy about performing a side-effect in a method which main purpose is to return a boolean indicating whether an entry is still valid.
If you have a better idea let me know :)

[Julien-R44]

Not a huge problem imo. We are also doing this in isTagInvalidated. But agree with you that its semantically incorrect

[Julien-R44]

Thanks a lot for the PR and sorry forlate reply, i have been pretty busy these last weeks...

Just a quick ( and maybe naive) question: instead of doing a double round-trip to check hard and soft tag keys separately, what about storing some metadata inside the tag value?

Something like:

await this.stack.set('___bc:t:users', { timestamp, type: 'hard' | 'soft' })

[yss14]

@Julien-R44 Any thought on how we should solve the naming conflict of deleteByTag and expireByTag?
I see the following options

1. Introduce a breaking change since effects of deleteByTag now "hard deleting" cache entries only has the consequence that potentially more cache entries must be fetched fresh from the datasource.
2. Only keep deleteByTag by now and defer the breaking change for the next major release. deleteByTag({ tags }) (no extra options) should behave as before: only soft invalidation (expire), not hard delete. Extend DeleteByTagOptions with something like hardDelete?: boolean, default false.
3. Come up with two completely new names for hard deleting entries by tag and expire entries by tag. Mark the "old" method deleteByTag as deprecated, but keep it for backwards compatibility.