Adding a registry column will require re-ingesting everything. Perhaps we should leave this until the Gen3 middleware cutover?

Sorry, I wasn't paying attention after this went into the headers not the opdb. Why do we need this in the registry (which is just an optimisation)? That is, what code needs to select data based on this entry?

"what [source] was that taken with?" and "what is the last set of SuNSS data?", etc. seem to be pretty common questions. That's all. fitsheader ...../2021*/sps/* is no fun anywhere, especially on GPFS, and opdb queries require some construction and take some interpretation (that could also be fixed).

Given that you don't have any general SQL access to the registry (except by opening it from the command line with sqlite3) I don't think that DB queries to the butler registry are the correct solution here.  I'm not especially against it — it's no big deal to reingest all the data, but this seems much more like an opdb query than a butler one.  Gen3 does provide more general SQL, but it's still designed for processing than interrogating the data.

So, sure; we can do this but I'd like to think about whether this is the right solution.  Generically Rubin is missing what we're calling "campaign management" to manage processing and analysis, and I suspect that that fits better into that bucket.  It could be the same back-end database, of course.

This is one of the questions I raised during yesterday's PU Group telecon. I'm certainly OK with it going through the opDB as it's good to have one central place from which to interrogate data.

cloomis: shall we file a new ticket on the opDB and close this one?

These are orthogonal questions.   Yes, this should be in the opdb, and we are going to put it in the header.   The question in this ticket is whether we extract the header value (possibly patched) into the registry as a convenient cache.