# Alert schema changes

**URL:** <https://www.rubin.community/t/alert-schema-changes/8727>\
**Category:** Alerts & Brokers\
**Tags:** schema\
**Created:** [June 13, 2024, 10:51am UTC](https://www.rubin.community/t/alert-schema-changes/8727 "2024-06-13T10:51:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![roy](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/roy/32/1254_2.png) [@roy](https://www.rubin.community/u/roy)\
**Post date:** [June 13, 2024, 10:51am UTC](https://www.rubin.community/t/alert-schema-changes/8727/1 "2024-06-13T10:51:44Z")

</div>

The Lasair team has a few questions about changes in the alert schema.

- We note that standard names have been adopted across all of `diaSource`, `diaForcedSource`, and `diaNondetectionLimit`, namely these six attributes:  
`ra, dec, band, midpointMjdTai, psfFlux, psfFluxErr`.  
As a result, the Lasair codebase has been changed to use these names consistently throughout. Can we assume that these particular names will not change again?

- We note that the schema change from 7.0 to 7.1 involves adding two and removing two attributes. Would it be possible to get a summary of changes in some kind of human readable quasi code, for example  
` diaForcedSource add column ra double, dec double diaForcedSource drop column x, y`

- We are thinking it is lightcurve features where the majority of schema changes will happen, is that right? (As in [DMTN-118](https://dmtn-118.lsst.io/)). Already there are simple per-band statistics like `psfFluxMean` and` psfFluxChi2`, but more will be added. These kind of additions are easy for Lasair to handle. However, our users will build queries against these attributes, therefore it would be great to know that once a feature is added to `diaObject`, it will not be removed.

---

<div class="post-metadata">

**Author:** ![ebellm](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/ebellm/32/771_2.png) [@ebellm](https://www.rubin.community/u/ebellm)\
**Post date:** [June 13, 2024, 4:30pm UTC](https://www.rubin.community/t/alert-schema-changes/8727/2 "2024-06-13T16:30:37Z")

</div>

Hi @roy ,

- I think it is likely these will remain unchanged going forward
- I don’t know that I’d use “quasi-code”, but you’re right to request a changelog. I’ll see that we add something to [GitHub - lsst/alert\_packet: Alert schemas in Avro format.](https://github.com/lsst/alert_packet).
- I think it’s correct that most of the changes are likely to come in the lightcurve features, but there are other fields that we think may require attention as well (for example, the model comparisons between PSF, dipole, and trail fits).

In general, at least until real LSSTCam alert production begins the AP team will continue to consider making breaking schema changes that are backwards incompatible. While we recognize that this is disruptive in the short term it seems preferable to carrying vestigial columns around for a decade. By necessity such changes should slow once we have a production database that must be migrated.

---

<div class="post-metadata">

**Author:** ![roy](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/roy/32/1254_2.png) [@roy](https://www.rubin.community/u/roy)\
**Post date:** [June 14, 2024, 7:07am UTC](https://www.rubin.community/t/alert-schema-changes/8727/3 "2024-06-14T07:07:48Z")

</div>

Thank you Eric. Of course at this time we can just delete all data and start again. But once the real data is in the database, we will all tread much more carefully.