{{ message }}
Repository navigation
SIMBAD cache question #3530
Description
@ManonMarchand in #2954, the caching machinery was removed in favor of lru_cache. My understanding is that this cache does not persist between sessions, it's purely in-memory, which is quite different from the previous mode.
Did you give any thought to a means for session-to-session caching as we had previously? This was my main use case. I discovered today that I'm unintentionally spamming SIMBAD with massive numbers of repeat requests because I thought I was using cached queries but was not.
@bsipocz do you have any feedback on this? The caching system was the source of some user problems in the past, but it was incredibly useful.
Activity
bsipocz commentedon Feb 12, 2026
As I recall none of the pyvo dependent modules have any meaningful cache as pyvo doesn't really have it.
Would it be useful to have something similar to the previous system? Probably; but I suppose it's a non-trivial amount of work to make it work well (while I'm not sure if we fully addressed vectorization issues).
keflavich commentedon Feb 12, 2026
Thanks. The 'lots of work' problem is legit, and I think it's quite reasonable to expect users to make one-off caches for specific use cases - it's not that hard. I may be the only one who was relying on the 'hidden' caching system.
bsipocz commentedon Feb 12, 2026
The issue is that we never really resolved the cache invalidation problem and that hidden directory more often than not got out of hand causing problems especially on systems where one has a very limited amount of storage space.
ManonMarchand commentedon Feb 13, 2026
Yes, the reason was that the cache system does not exist for classes which only depend on
BaseVOQuery. We'd actually really like it if it could work as it would reduce the load on our servers. I started thinking about it but never got the time to actually implement it.The requirements I had in mind were:
PS: I removed the simbad tag as this is actually the case for every sub module based on a VO API