Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

RFE: Reverse queries #47

Open
hunterhacker opened this issue Nov 19, 2011 · 3 comments
Open

RFE: Reverse queries #47

hunterhacker opened this issue Nov 19, 2011 · 3 comments

Comments

@hunterhacker
Copy link

At some point Corona should support reverse queries.

I picture letting the user save queries with names. Then execute a reverse query on each document insert or modification (easy to do when in a managed context, could still use triggers and CPF when not). Let the user indicate what should happen on a new match. Expose some decent primitives for them to choose from: invoke a url, email out, make note in a way that can be polled later, run some uploaded code, etc.

@ghost ghost assigned ryangrimm Nov 19, 2011
@hunterhacker
Copy link
Author

Idea for how to build this:

Let users manage named alerts

Each alert gets a string or structured query dictating which docs match

Each alerts also gets a URL to callback to, with optional auth, when a doc matches.

Each doc insert or modification through Corona does a reverse query to check on matches.

Any match hit invokes the callback URL, passing the name of the alert and the doc uri that matches.

It'd be good if the post to the callback URL could optionally pass the doc itself, with all the regular options that document fetching provides (extractPath, applyTransform, include options, etc). The wrapper of the data posted should look like a regular document fetch, except it'll need a the alert name added I suppose.

@collwhit
Copy link

collwhit commented Dec 1, 2011

Seems like named saved queries could be used for more than alerting, e.g. queries that can be rerun on demand, registered queries.

Is it all or nothing on doc inserts? Or scoped (e.g. directory or collection)?

@hunterhacker
Copy link
Author

On reuse... Great point! If queries can be persisted with a name, it would be natural to be able to include them in other queries (i.e. structured queries or even string queries) referenced by name. I could see people doing a lot of that actually. Slick.

Yes, we should register them. I don't think that should be the only path to registration, but should be one.

Scoping... Seems like since you can limit to a directory or collection or both in the query itself (i.e. alert me when a doc in this directory in this collection appears with this word), so I don't think that needs to be broken out. Just put it in the query. At least that's what the user's view should be.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants