Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query events by subscription filter #1443

Open
nguyer opened this issue Jan 10, 2024 · 2 comments
Open

Query events by subscription filter #1443

nguyer opened this issue Jan 10, 2024 · 2 comments
Milestone

Comments

@nguyer
Copy link
Contributor

nguyer commented Jan 10, 2024

Subscriptions have a filter on them, which is applied to events as they appear in the event stream to determine if they match the subscription.

This filter is spelt with a JSON semantic that is completely unique to subscriptions:
https://hyperledger.github.io/firefly/head/reference/types/subscription.html#subscriptionfilter

So if you wanted to browse the history of messages that would be delivered to your subscription, and look at where the offset of your subscription is up to in that stream, it's a really hard thing to do!

You have to construct an API query from scratch, that you believe is accurate compared to what FireFly is constructing internally in Go code.

So, this enhancement request is to instead provide a simple API GET endpoint underneath a subscription to ask FireFly to do that query-building for you.

e.g. you get a collection API that's pre-filtered by all the filtering that's part of your SubscriptionFilter, and when you do queries on top of it (like id=xyz or created=>...) you're adding an additional set of filters on top of the filters already in place.

@nguyer nguyer added this to the v1.3.0 milestone Jan 10, 2024
@peterbroadhurst
Copy link
Contributor

The wrinkle here, is that SubscriptionFilter applies filters as a Regular Expression, and currently we don't have support for regular expression filters in our DB semantics.

So I think the most straight forward and determinsitic way to build this feature is:

  • Run the DB query without skip and limit from the API call (use our own internal skip + limit)
  • Use the existing go code from the filtering that is done in the subscription to post-filter these
  • Loop on the skip + limit in our internal loop, until we've fulfilled the skip + limit on the external

@SamMayWork
Copy link
Contributor

PR for this now open at #1452

@nguyer nguyer modified the milestones: v1.3.0, v1.next Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants