New Feature: Add query filter by key substring

[pyropy]

• Add new filter to enable query by key substring

[welcome[bot]]

Thank you for submitting this PR! A maintainer will be here shortly to review it. We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the rest) and in its best form. Follow the code contribution guidelines if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment. Next steps:

• A maintainer will triage and assign priority to this PR, commenting on any missing things and potentially assigning a reviewer for high priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution. We are very grateful for your contribution!

[guseggert]

Hi @pyropy, thanks for the PR. Can you explain your use case here? Also could you use this without adding it to go-datastore?

[pyropy]

Hi @guseggert, I'd like to query complex keys by substring, for example let's say I have keys like this /5/4/fe175c1f-25ff-455d-ae43-f21097e879c6/10:10, /5/4/fe175c1f-25ff-455d-ae43-f21097e879c6/9:10, /5/4/fe175c1f-25ff-455d-ae43-f21097e879c6/8:10 and I would like to query all items where key contains substring UUID fe175c1f-25ff-455d-ae43-f21097e879c.

This is my primary use-case and reason I've opened this PR. I would love to know if there is some other way to achieve this?

[Jorropo]

The query package is slow already but the filters that exists could be made fast if we needed to (sorted indexes, binary search, other fancy db things, ...), contains just couldn't and will probably have O(N) complexity forever.

Given that everything you need is exported (the Filter interface, ...) this filter can live in different repos and be used just the same.