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