1# PerfettoSQL: backwards compatibility 2 3PerfettoSQL tries its hardest to minimize backwards incompatible changes but occasionally they are unavoidable. 4In situations where we need to make such changes which we expect to have non-trivial impact, this page 5documents: 6 - **Date/Version**: the date of this change and the first release of Perfetto with the change 7 - **Symptoms**: unexpected behavior or error messages you would see if you are affected by the change 8 - **Context**: why we are making the change i.e. why does it have to backwards incompatible? 9 - **Migrations**: suggested changes you can make to your PerfettoSQL to not be broken by the changes 10 11## Change in semantic of `type` column on track tables 12 13**Date/Version** 14 152024-12-18/v49.0 16 17**Symptoms** 18 19 - The value of the `type` column changing from output of queries which query a `*track` table 20 - Missing rows if you have constraints on the `type` column. e.g. 21 `SELECT type from track where type = 'process_slice'` will now return zero rows 22 23**Context** 24 25NOTE: this change is very closely tied to *Removal of `type` column from non-track tables* change, 26see below. 27 28The `type` columns on track tables has been around for a long time and indicated the "most specific 29table" containing the track. Over time, with changes in how tables in trace processor tables are 30structured (i.e. more use of the standard library, tracks with multiple dimensions), we have outgrown 31the idea of "object-oriented tables" which made the `type` column meaningful. 32 33Instead of the handful of possible `type` values (e.g. `process_track`, `thread_track`, `counter_track`) 34we have switched the semantic of the `type` column to indicate the "type of data in the track". For 35example, for global scoped slice tracks coming from `track_event` APIs, the `type` column would now be 36`global_track_event`. For process scoped tracks, it would be `process_track_event` etc. 37 38This change very closely ties to the new column `dimension_arg_set_id` which also contains `type` specific 39context identifying what makes the track distinct among all tracks of the same `type`. 40 41**Migrations** 42 43If you were doing queries of the form `select * from track where type = 'process_track'`, this can easily 44be changed to `select * from process_track`. 45 46Instead if you were trying to export the value of `type` out of trace_processor, you can recover the old 47type column by doing multiple unions on track. 48 49For example, instead of: 50 51```sql 52select name, type from track where name in ('process_track', 'thread_track') 53``` 54 55you can do: 56 57```sql 58select name, 'process_track' as type from process_track 59union all 60select name, 'thread_track' as type from thread_track 61``` 62 63Finally, the suggested way of find all "globally scoped tracks" before this change was to do: 64 65```sql 66select * from track where type = 'track' 67``` 68 69This can be replaced with: 70 71```sql 72select * from track where dimension_arg_set_id is null 73``` 74 75## Removal of `type` column from all non-track tables 76 77**Date/Version** 78 792024-12-18/v49.0 80 81**Symptoms** 82 83 - An error message of the form `no such column: type` 84 - The `type` column disappearing from output of queries with `SELECT *` 85 86 87**Context** 88 89NOTE: this change is very closely tied to *Change in semantic of `type` column* change, see above. 90 91The `type` columns on tables has been around for a long time and indicated the "most specific 92table" containing the track. Over time, with changes in how tables in trace processor tables are 93structured (i.e. more use of the standard library, tracks with multiple dimensions), we have outgrown 94the idea of "object-oriented tables" which made the `type` column meaningful. 95 96In fact for any non-track table, the type column was almost always just equal to the name of the 97table itself e.g. if you do `select type from slice`, the type column would be `slice`. 98 99Given the very limited utility of this column, the fact that it costs us a non-trivial amount of memory 100to store this information on large traces and that it pollutes the lists of columns, we are removing 101this column from all non-track tables. For track tables, the purpose of this column has changed as 102discussed above. 103 104**Migrations** 105 106It's very likely that your dependence on `type` was an accident by doing `select *` and not an active 107choice. In this case, migration should be trivial by just removing references to the `type` column (e.g. 108in assertions on the output of queries with `select *`). 109 110If your workflow is now broken by this change, we would be interested in helping you resolve this issue. 111Please file a bug at http://go/perfetto-bug (if you are a Googler) or 112https://github.com/google/perfetto/issues/new (otherwise). 113