4 ms·

This is an excellent question, and it's one of the areas where we think we can do some pretty novel things with our approach. There are a two main cases of thi

This is an excellent question, and it's one of the areas where we think we can do some pretty novel things with our approach. There are a two main cases of this idea that we have spent time thinking about. 1. Truly static report. Here, you would need to condition your SQL queries so that they continue to return the same results over time. E.g. your `where` clause restricts the results to 'on or before' the day of writing. Evidence will continue to build the report on a schedule, but the results will never change so long as your historical data is constant. You can do this today. In a future state, we've talked about rendering a snapshot of the report and checking that into version control, so that even if your underlying data is a moving target, you can hold onto what the report looked like at a moment in time. We're kind of mixed on that idea of snapshotting reports themselves though, it's just so much better to build your data warehouse such that it is actually retaining the historical data, but we recognize sometimes that's not practical. TBD on that functionality. 2. Recurring report with static commentary Here, you have a recurring time-bounded report, and you occasionally want to mix-in commentary that's only relevant for specific time periods. With Evidence, (this part is from svelte kit) you can mix paramaterized pages, and static pages on the same route. So if you had 'monthly mrr growth report', you could use a parameterized page to generate the report for every month into history and into the future, AND, you could include versions of the report with hand-written commentary for any specific months where it was needed. So if someone navigates to the February 2021 page, they get the standard parameterized version, but if they go to January 2021, they get the handwritten January version that explains that there was an acquisition which drove the big pick-up in MRR. This one is a bit tricky to explain, but we will build some examples.

101008 5y ago
Thanks for answering. The approach about adding the date on the where clause may not work. I may receive/ingest more data from that point in time after I made the report. Of course, the report wouldn't be updated, but I'd prefer to have an updated report that says "We did it witht he data available at this time" and not one that says one thing but shows a different thing. Kudos on the launching anyway!
- amcaskill 5y ago
  Good point. Late arriving data is such a challenging problem. Perhaps if you have the load date, you could condition on that. We will think about the 'snapshot the outputs' approach as well.
webmaven 5y ago
> In a future state, we've talked about rendering a snapshot of the report and checking that into version control, so that even if your underlying data is a moving target, you can hold onto what the report looked like at a moment in time. > We're kind of mixed on that idea of snapshotting reports themselves though, Right. In terms of a code-oriented version control service like GitHub, you shouldn't be checking in the rendered reports unless you want people modifying them directly (and they will) and submitting PRs. Instead, consider attaching the generated report artifacts as releases* associated with a tag (or possibly a branch) in the version-controlled source, and you get a few helpful conventions and affordances. OTOH, you are then sort of constrained to reviewing a release (or release candidate) with the built-in functionality only in the unrendered-but-version-controlled source, which probably isn't what you want.
Aeolun 5y ago
I’m confused. I understood this to generate static pages. If you never update them, the report wouldn’t change right? E.g. it executes the queries during build time, not on every load.
- amcaskill 5y ago
  You are correct that Evidence executes queries at build time, not at load time. In a production environment for business reporting we would expect users to be building their project a few times a day, if not more often. For example, we compile all of our KPIs for evidence into an evidence project, and we trigger a build of that project twice a day so that it has up-to-date metrics for us. Your question is making me think about what an incremental build strategy could/should look like, but that’s a bit down the road for us.
  - Aeolun 5y ago
    Probably not worth it to do incremental I think. At least, unless your reporting queries take ages (now that I say that, I can practically guarantee that someone is going to think it’s normal to have a report run for several days) Either way, my point was that if the final output is a few static HTML files, it’s probably not too much of a problem to save literally every iteration of a report.

101008 5y ago

Thanks for answering. The approach about adding the date on the where clause may not work. I may receive/ingest more data from that point in time after I made the report. Of course, the report wouldn't be updated, but I'd prefer to have an updated report that says "We did it witht he data available at this time" and not one that says one thing but shows a different thing. Kudos on the launching anyway!

amcaskill 5y ago
Good point. Late arriving data is such a challenging problem. Perhaps if you have the load date, you could condition on that. We will think about the 'snapshot the outputs' approach as well.

webmaven 5y ago

> In a future state, we've talked about rendering a snapshot of the report and checking that into version control, so that even if your underlying data is a moving target, you can hold onto what the report looked like at a moment in time. > We're kind of mixed on that idea of snapshotting reports themselves though, Right. In terms of a code-oriented version control service like GitHub, you shouldn't be checking in the rendered reports unless you want people modifying them directly (and they will) and submitting PRs. Instead, consider attaching the generated report artifacts as releases* associated with a tag (or possibly a branch) in the version-controlled source, and you get a few helpful conventions and affordances. OTOH, you are then sort of constrained to reviewing a release (or release candidate) with the built-in functionality only in the unrendered-but-version-controlled source, which probably isn't what you want.

Aeolun 5y ago

I’m confused. I understood this to generate static pages. If you never update them, the report wouldn’t change right? E.g. it executes the queries during build time, not on every load.

amcaskill 5y ago
You are correct that Evidence executes queries at build time, not at load time. In a production environment for business reporting we would expect users to be building their project a few times a day, if not more often. For example, we compile all of our KPIs for evidence into an evidence project, and we trigger a build of that project twice a day so that it has up-to-date metrics for us. Your question is making me think about what an incremental build strategy could/should look like, but that’s a bit down the road for us.
- Aeolun 5y ago
  Probably not worth it to do incremental I think. At least, unless your reporting queries take ages (now that I say that, I can practically guarantee that someone is going to think it’s normal to have a report run for several days) Either way, my point was that if the final output is a few static HTML files, it’s probably not too much of a problem to save literally every iteration of a report.