I'm not sure why we didn't do it already, but running Koha in a persistent
context has become the standard.
This means variables defined as `our $variable` will persist in memory
while workers run. And this is dangerous for several reasons. The most
obvious one is that sometimes the code expects t
I believe you are correct. IIRC some of the times we've attempted to simply
swap `our` for `my` it has created issues with the code. Swapping the
variable for a caching mechanism definitely sounds like the way to go! I'm
seeing a lot of `our` keywords that appear to be functionally constants,
and s
My answer from bug 38357 comment 15:
"""
It has a global scope, and is available from the subroutines.
When switching to plack we (lazily) switched some "my" to "our" to
just make things work.
It can be fixed, but it's not simply a s/^our/my/g substitution.
But yes, it must be done.
"""
Le mer. 12
Yeah, I'd advocate for a 'fix as seen' basis instead of a whole rewrite
project. But yeah.
El mié, 12 mar 2025 a las 8:18, Kyle Hall ()
escribió:
> I believe you are correct. IIRC some of the times we've attempted to
> simply swap `our` for `my` it has created issues with the code. Swapping
> the
I'm in.
El mié, 12 mar 2025 a las 9:36, Jonathan Druart ()
escribió:
> This one smells bad:
> tools/exceptionHolidays.pl
> 43 our @holiday_list;
>
> As well as all the "our $tagslib": big structures (marc subfields) are
> kept in memory.
>
> I think we should at least fix the easy ones, I am will
