Richer Provenance #44

New Issue

Open

opened 2023-07-05 09:45:13 +02:00 by thm · 1 comment

thm commented

2023-07-05 09:45:13 +02:00

Owner

Right now, provenance is just a string, but it's already apparent a little more nuance is needed:

API-originated?
Implicit or Explicit?
- Did this end up being committed because of something like a navigation, or by an explicit decision to make a connection?
Result of an import? (#43)
Which user? (#16)

Technically, the UpEnd underlying model can handle all of this, but a simpler approach was chosen for performance's sake. Right now, it works, but it might just end up being an User-Agent string kind of scenario.

Right now, provenance is just a string, but it's already apparent a little more nuance is needed: - API-originated? - Implicit or Explicit? - Did this end up being committed because of something like a navigation, or by an explicit decision to make a connection? - Result of an import? (#43) - Which user? (#16) Technically, the UpEnd underlying model can handle all of this, but a simpler approach was chosen for performance's sake. Right now, it works, but it might just end up being an [User-Agent string](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent) kind of scenario.

thm added the

query lang

backend

structure

labels 2023-07-05 09:45:13 +02:00

thm commented

2023-07-06 10:23:06 +02:00

Poster

Owner

For performance's sake, we could add a JSON-like structure (or just multiple columns) for provenance (since that's the couple fields that will exist for nearly every entry); and allow querying as if they were physical entries. (What's the mechanism for virtual entries?)

For performance's sake, we could add a JSON-like structure (or just multiple columns) for provenance (since that's the couple fields that will exist for nearly every entry); and allow querying *as if* they were physical entries. (What's the mechanism for virtual entries?)