# Coping with deprecated columns in Data Explorer
**URL:** https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264
**Category:** Feature
**Tags:** data-explorer
**Created:** [April 9, 2026, 3:46am UTC](https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264 "2026-04-09T03:46:40Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@ted](https://meta.discourse.org/u/ted)
#### Post date: [April 9, 2026, 3:46am UTC](https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264/1 "2026-04-09T03:46:40Z")
One infrequent but annoying problem is [Data Explorer](https://meta.discourse.org/t/32566?silent=true) queries can start breaking when columns are dropped and renamed in core or plugins. Downstream this can cause automations to start failing.
To that end, I have opened one PR here, which will mark columns as deprecated in the [Data Explorer](https://meta.discourse.org/t/32566?silent=true) schema explorer (heh):
[https://github.com/discourse/discourse/pull/39173](https://github.com/discourse/discourse/pull/39173)
This is small comfort which will mostly help when creating new queries, but it is likely the most we can do without introducing a SQL parser as a dependency into core.
However I’m keen on expanding this to also:
1. display a warning on queries that are using deprecated columns, and
2. add a problem check that can surface these issues in the admin notices section of the dashboard.
The second one would be the ultimate way of giving admins a heads up before being taken by surprise when upgrading.
Would you be okay with introducing a gem to do SQL parsing to support this feature @sam? It could be `require`d only when [Data Explorer](https://meta.discourse.org/t/32566?silent=true) is loaded.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [April 9, 2026, 4:42am UTC](https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264/2 "2026-04-09T04:42:20Z")
> [@ted](#):
>
> Would you be okay with introducing a gem to do SQL parsing to support this feature @sam? It could be `require`d only when [Data Explorer](https://meta.discourse.org/t/32566?silent=true) is loaded.
Hi Ted 🤗
Honestly, I am not sure, everything depends. The good news is that Nat and @tgxworld are looking at [data explorer](https://meta.discourse.org/t/32566?silent=true) at the moment so they should be able to provide guidance.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [April 17, 2026, 5:57am UTC](https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264/3 "2026-04-17T05:57:37Z")
I’m mostly OK with the idea here but I don’t think everyone is religiously deprecating columns that is a prerequisite for this feature to be useful. Not sure but can we determine if a column is considered deprecated based on whether the column has been marked as readonly in the database? That is a much more reliable signal as to whether a column is going to be deprecated or not IMO.
---
### Author:  [@ted](https://meta.discourse.org/u/ted)
#### Post date: [April 22, 2026, 9:46am UTC](https://meta.discourse.org/t/coping-with-deprecated-columns-in-data-explorer/400264/4 "2026-04-22T09:46:53Z")
I assume you mean using `ignored_columns` in the model? We can (and should) definitely include this.
I added it in this commit:
[https://github.com/discourse/discourse/pull/39173/changes/374812537cefe8e869a72a384a50d8fd528c8a88](https://github.com/discourse/discourse/pull/39173/changes/374812537cefe8e869a72a384a50d8fd528c8a88)