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?

That's disappointing, thanks for letting me know though!

Yes, it looks like you can replace path with ip_address and tcp_port in the call to open

So something like

...
// Open the connection to the Caché database (adjust parameters for your Cache system):
let ok = db.open({
  ip_address: "127.0.0.1",
  tcp_port: 1972,
  username: '_SYSTEM',
  password: 'SYS',
  namespace: 'USER'
});
...

My cheeky solution was 

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

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

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

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

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!

Thanks for answering Luca - that's good to know.

Though if there's no durable %SYS, how do we handle persistence for Cache and Ensemble Docker containers? It doesn't sound fully supported if I lose data every time my container exits :)

I understand regarding the licensing, I'm sure our sales engineer can provide us more information about that.

So to clarify - Cache will NOT have durable %SYS support and not be fully supported under Docker? Or Cache will support durable %SYS in the next version, which is not yet released?

The only things I've heard so far about upgrading from Cache to IRIS is that "the installer doesn't support upgrading anyhow" (from Benjamin DeBoe) and that all our sites would require "a different license key" (from the WRC IRIS Distribution page) - which sounds a little less convenient and easy :)

What date is the Zen end-of-life planned for (ie. when is it supported until and when will it be removed)?

-On Persistence: Obviously your data must be mounted on a volume. One of the nice things about containers is the clear demarcation between code and data. As far as Caché system data is concerned, like the cache.cpf file and %SYS we are working on a solution that will make Caché a 1st class citizen of the container world and it will be very easy to use and upgrades will just work.

This sounds perfect - can you possibly elaborate on details/timeframe?

We're rolling out Cache on Docker over the next few months, so it would be really nice to know to what extent we should roll our own infrastructure in the interim :)

Those are two very good points! Thanks for taking the time to elaborate.

No worries, give me a couple of days - I'll let you know when it's up.