Filter IDs are unstable and breaking scripts

Equipment database Issue report
AstroBin Platform open discussions community forum •3 replies•48 views
Support requests are handled via the support form so they can be tracked and resolved properly. This section is for community discussions about the AstroBin platform.
YingtianZZZ avatar
YingtianZZZ avatar

I wrote a script to generate CSV files so I don’t have to manually enter every imaging session. The script itself is fine. The filter IDs are the problem.

I’m using Optolong 2″ filters. The time when I first wrote this, Optolong 2″ Red had ID 1245, while the rest of the Optolong 2″ filters were continuous from 3103–3108. That made no sense, but fine.

Today I reused the same script and the site told me filter 3107 does not exist. I checked 3107 was SII, so I had to manually enter it just to continue.

Then I checked the filter list again. ID 1245 is no longer Optolong 2″ Red and is now some generic Optolong Red category. The Optolong 2″ SII 3nm filter, which used to be next to the other Optolong 2″ filters, is now ID 5523. Different number for 2/7 filters in one month.

So now filter IDs are not continuous, not stable, and can change over time. Are these numbers just internal database IDs and what users are supposed to rely on? What is the correct and stable way to reference a filter without everything breaking later?

Salvatore Iovene avatar
Salvatore Iovene avatar

Hi,

thanks for bringing this up to my attention.

The fact that filter ids are non contiguous is not a problem in my eyes, because they might as well be random UUIDs. They are not necessarily created in sequence, but when people add them to the database as they need them.

However, the fact that they are not stable is a problem that I should rectify.

To explain: filter IDs are not stable only when the filter is not approved, as the filter could be duplicate of another and later merged into it.

This is no excuse tho, as they could be made to be stable via redirects.

I'll add this to my urgent list. If there is an audit table for equipment merges (can't recall off the top of my head) then I can make this retroactive, which would be great (IDs are never reused).

Thanks again and I will update you here when this is done.

Salvatore

Helpful Insightful Respectful
Salvatore Iovene avatar
Salvatore Iovene avatar

I'm almost done writing the code for this and I have good news. Moving forward, once this is tested and deployed, this will stop being an issue. Moreover, this can be made retroactive for filters rejected as duplicates before this special handling was implemented!

Well Written
YingtianZZZ avatar
YingtianZZZ avatar

Salvatore Iovene · Jan 8, 2026, 01:34 PM

I'm almost done writing the code for this and I have good news. Moving forward, once this is tested and deployed, this will stop being an issue. Moreover, this can be made retroactive for filters rejected as duplicates before this special handling was implemented!

Great! I’ll take a recheck for my 3 settings script after they are available, and thank you for your help!