That's very useful to know!

Can you clarify how often should this be run - Just once? Or on every boot? Or on every application upgrade where queries may have changed/been added?

I'd also like to see release notes, but in case they're not available yet, does this support the new durable %SYS?

My cheeky solution was 

r=1:1:! c=1:1:w:r#s<2!(c#s<2)!(c=r)!(s-r+1=c) "#" " "

I'm not sure if it will copy/paste properly, but there's a backspace character in the string before the #  laugh I considered it cheeky because despite looking correct in the terminal it's definitely not if you compared it byte for byte wink

70 or 73, depending on how cheeky you'll let me be wink

edit: 69 for my cheeky solution, the other one was the same as Zenkov's below but I wasted a character on a for bracket because I foolishly put my newline on the other side of the $s()

We implemented an Asset Pipeline (before the days where nice things like webpack existed). It's pretty ugly, only builds on windows and requires a few hooks into the zen page component, but works well and significantly reduces the amount of round trips + makes them fully cacheable. The performance boost is nice, but the drop in "have you cleared your browser cache?" support requests is even better ;)

Asset Pipeline on the left, stock Zen on the right

Asset Pipeline on the left, stock Zen on the right

If you're interested I can add some docs and throw it up on github for you?

Our production systems use deployed obj code, so we can't upgrade cache versions without a new set of cache.dat's. We've been thinking a bit about how to best go about this as well.

Right now version jumps are a bit of a major effort and we're lagging behind on 2014.1. We're hoping to solve this with Docker for our linux sites - essentially by bundling cache with our product and distributing it all as one self-contained unit. Not too sure how to do this with windows yet (msi installer?).

That way our dev/test/prod upgrade process becomes "docker run $product:latest" or "msiexec /i $product-latest.msi". Docker/msi contain whatever version of cache the product version requires, rather than expecting the correct version to be installed (and potentially breaking if it isn't) .

Still yet to roll this out - I'll let you know how it goes (or has anyone else done something similar? ;)

OT: I couldn't add this as an "answer" (get the option to type it in, but the only buttons are Save & Preview). Not sure where this comment will go..

Hmm, in my tests I remember Cache not starting cleanly without a journal.log present. I'm not sure if this is still the case it's been quite a while since I tried this. I'll have to take another look.

I was more concerned as to how Cache (eg. CACHELIB - the code) would react to different versions of the CACHE system databases (eg. CACHESYS/CACHE - the system data). What I'm understanding from you is that using the CACHESYS/CACHE databases from a 2017.1 system in a 2017.2 docker image, with no Cache upgrade would be fully supported - correct?

Yeah, my "creative" solution prior to the durable %SYS announcement was to:

  • Export all system parameters to a volume every 30 seconds in case of crash (reasoning that they probably wouldn't change that often). And import them prior to Cache boot.
  • Configure the WIJ to be stored in a volume
  • Configure the journals to be stored in a volume
  • Possibly store the audit database on a volume? Idk we don't currently make use of it.

I hit a showstopper as it does not seem possible to relocate the journal.log file (via symlink or any other means). I did submit a product development request to change this, unfortunately it was denied. It seems without this file the journals cannot be recovered so we can never truly separate code and data in Cache :(

I noticed that the durable %SYS feature relocates everything in the mgr directory except the CACHELIB database. I was hesitant to do that because I wasn't sure how a 2017.2 Cache system would handle 2017.1 data after version upgrade. I'm still not 100% sure to be honest - would this be a "fully supported" use of Cache under Docker?

Of course, if you have any other creative thoughts I'm all ears!