Skip to content

🎉 Charts as first-class ETL citizens via simple mdims#5969

Closed
pabloarosado wants to merge 10 commits into
masterfrom
data-charts-etl-emptydimensions
Closed

🎉 Charts as first-class ETL citizens via simple mdims#5969
pabloarosado wants to merge 10 commits into
masterfrom
data-charts-etl-emptydimensions

Conversation

@pabloarosado

@pabloarosado pabloarosado commented Apr 23, 2026

Copy link
Copy Markdown
Contributor

Summary

Allow charts to be created and edited from ETL, as a special case of mdims (instead of creating a new Graph object, as in this old PR).

Additionally:

  • Support export steps with just a config file (without a .py file).
  • Adapt VSCode extensions.
    • Also adapt chart preview to be able to visualize draft charts.
  • Adapt tests, version tracker, and step updater.
  • Create an example chart config etl/steps/export/multidim/animal_welfare/latest/banning_of_chick_culling.config.yml.

To be discussed

  • The old PR had a way to pull and push grapher configs, but we weren't sure about this approach. Currently, we have linked and unlinked metadata fields in grapher charts. Those fields come from ETL. I'm wondering if we could extend that logic to other (or all?) grapher fields.

@owidbot

owidbot commented Apr 23, 2026

Copy link
Copy Markdown
Contributor

Quick links (staging server):

Site Dev Site Preview Admin Wizard Docs

Login: ssh owid@staging-site-data-charts-etl-emptydimensi

chart-diff: ❌
  • 0/2 reviewed charts
  • Modified: 0/1
  • New: 0/1
  • Rejected: 0
  • Data changes: 0
  • Metadata changes: 1

Edited: 2026-04-28 05:46:09 UTC
Execution time: 5.14 seconds

@pabloarosado pabloarosado changed the title 📊 Charts as first-class ETL citizens via empty-dimensions detection 🎉 Charts as first-class ETL citizens via simple mdims Apr 23, 2026
@pabloarosado pabloarosado marked this pull request as ready for review April 23, 2026 21:35
@Marigold

Copy link
Copy Markdown
Collaborator

@codex review

Comment thread etl/collection/chart_upsert.py

@Marigold Marigold left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat, I'm surprised how elegant this is compared to the previous PR. After you merge it, I'll make it work with Chart Preview in VSCode.

@lucasrodes lucasrodes left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, Pablo! Thanks for working and pushing for this. I've left two comments. One more on the "code design" side of things; the other is a minor concern about the source of truth/conflicts with chart configs.

Comment on lines +57 to +62
if existing is not None:
# Preserve publication state unless the user explicitly overrode it.
config.setdefault("isPublished", existing.config.get("isPublished", False))
log.info("collection.chart.update", slug=slug, chart_id=existing.id)
admin_api.update_chart(chart_id=existing.id, chart_config=config, user_id=user_id)
chart_id = existing.id

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if a chart already exists in DB, we can just overwrite it via ETL? Am I understanding it correctly?

Couldn't this cause unwanted overwrites? Say the chart exists in DB and is live (i.e., this if evaluates to True). If the config in ETL differs from that in the DB (because someone has edited it in either ETL or the DB), wouldn't the DB version always be overwritten?

I see that on staging, one can reject changes in the Chart diff (I suppose), but the ETL config still appears and may have been merged into master. Then, in master, if etl runs, the DB chart would be overwritten, no?

I'm just not sure I understand this logic. At the moment, it feels a bit dangerous, but I could be misunderstanding it.

Comment thread etl/collection/chart_upsert.py
@pabloarosado

Copy link
Copy Markdown
Contributor Author

Neat, I'm surprised how elegant this is compared to the previous PR. After you merge it, I'll make it work with Chart Preview in VSCode.

Thanks Mojmir! In principle Chart Preview should already work in this PR. I tweaked a few things and checked on a couple of examples, but I haven't checked thoroughly.

@pabloarosado

Copy link
Copy Markdown
Contributor Author

Closing this PR without merging; the good thing of the current approach is that no changes were required in owid-grapher. However, after various discussions, it seems that having a proper layered approach (making some changes in owid-grapher) is preferrable.
So, the new approach should be: this PR

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

Successfully merging this pull request may close these issues.

4 participants