[Koha-devel] frameworks and Bug 7432

Paul paul.a at aandc.org
Mon Jul 16 15:30:42 CEST 2012


At 02:37 PM 7/15/2012 -0400, Jared Camins-Esakov wrote:
>Using 3.6.1 in production (no longer on sandbox, we're looking at 3.8) 
>modifying frameworks never gave "instant gratification" due to memcached, 
>so I use netcat:
>echo -e "flush_all\nquit\n" | nc localhost 11211
>(and even have a temp 1 min cron job if I need more than a very simple 
>change.)
>
>If the only thing using memcached is Koha, you might find it easier to 
>simply have a cron job that runs `service memcached restart` every hour.

Koha is only about 10% of our memcached load, but I do cron "flush-all", 
"sleep 10" then "restart" every 24 hrs (at 3am, low/no use, gets around the 
time delay "gotcha".)  Also, as far as I know "restart" might not totally 
*flush* memcached (there's a lot of debate about it, particularly in the 
php world where memcached's garbage collection seems to be a dirty word) 
but I haven't done any serious testing.  At least "flush-all" is virtually 
instantaneous, and meets the needs of Koha frameworks.

>Do not mix and match files from different versions. My recommendation 
>would be to upgrade to a recent version of 3.6.x.

Thanks for the confirmation.  That was my gut feeling.  But ... I really am 
trying to avoid trashing the work I've done on 3.8 on the sandbox (which is 
too old to successfully run two versions of Koha.)  I'm nowhere near ready 
at this time to put 3.8 into production, so I guess my $64,000 question is 
"what is the most stable version of 3.6 that I can upgrade the production 
server to, with the least chance of running into problems?"  There's 
probably a lot of other bug fixes and enhancements that could be 
useful.  Maybe wait for your 3.6.7?  :=)

>[snip] (WARNING: the following is irrelevant to your question) I would 
>argue this is a bug (reported it as one, in fact), but that's the way it 
>is, so -- for the moment -- no need to mark both the tag and subfield 
>mandatory. Based on the way the MARC standard is written, marking a 
>subfield mandatory should make it so that if any subfield in that tag is 
>populated, that subfield must be populated, but not require that the tag 
>be populated at all. However, that's not the way it works, so it's kind of 
>a moot point.

Sorry, but I can't find the bug you reported (number?)  From my 
perspective, it was a [probaly very rare] combination of circumstances and 
as you say "a moot point", hence my calling it an "oddity" rather than a 
bug. We're back on track, the cataloguers see a red asterix, and the help 
file (ours, not LoC) pops up when requested.

Thanks again and regards,
Paul

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://NavalMarineArchive.com> and <http://UltraMarine.ca>



More information about the Koha-devel mailing list