Skip to content
This repository has been archived by the owner on Mar 30, 2019. It is now read-only.

Add generic /listen endpoint #17

Open
ncalexan opened this issue Oct 14, 2016 · 1 comment
Open

Add generic /listen endpoint #17

ncalexan opened this issue Oct 14, 2016 · 1 comment

Comments

@ncalexan
Copy link
Member

Datomish (and Datomic, and DataScript) have a concept of transaction listeners. The WebSocket interface to the UAS was always intended to model this concept, although right now the WS interface doesn't expose anything like transaction reports. This ticket tracks implementing such a listen interface, streaming application-edn back to the client. We might prefer to use Server Sent Events rather than WebSockets; SSE seem a little cheaper to set up and a little easier to consume.

As follow-up, it would be nice to be able to filter the transaction reports on the service rather than doing all filtering client side. The best possible would be to provide a query to match against the report, only providing the full details of matching reports, or only providing the query output for each report, or ... However, none of those options are trivial given our q implementation.

@rnewman
Copy link
Contributor

rnewman commented Oct 14, 2016

Some thoughts on filtering.

Consumers might wish to filter on several aspects:

  • The content of the transaction itself.
    • … simply: tell me about all transactions that include URLs.
    • … less simply: tell me about all transactions that add a person named Joe.
  • The content of the transaction in the context of the database. For example: we just transacted a :foaf/knows attribute. Is this a link between someone at Company X and a political party? Answering that question involves a trigger and a filter.

Note that 'less simply' is a subset of including the database in the query.

I propose, then, a trigger/filter system. A trigger is simply a function of the tx-report, probably derived from some specification from the consumer — "any transaction using attributes X or Y and e/v A or B". A filter is an optional query, parameterized on the txid of the transaction that committed, and evaluated in the scope of the database immediately after commit. If it returns results, the filter passes.

That means we have tiers of listeners:

  • Give me everything (no filter, no trigger): transaction log.
  • Give me all :page/save transactions (trigger but no filter): live update.
  • Give me all :foaf/knows transactions where either party is a person of interest (trigger and filter): change notification.

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

2 participants