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!

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

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 

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

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

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)?

Is there going to be a Cache/Ensemble Docker image with durable %SYS support, or is this going to be for IRIS only?

-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 :)

It's super satisfying being able to spin up full cache systems with a single command!

Have you got any strategies for persistence? Say I log in, add a cache user, edit some globals in USER and then notice Cache 2017.1 is out - how best to upgrade?

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.

We use a projection to generate and bundle assets for our zen components. So on compile, after css and js get regenerated our projection bundles and minifies it all into one file for the page to use instead of the dozens that otherwise get loaded.

I still remember asking the WRC guys about projections at a global summit a few years back. One of the fellows took me over to a lamp and made a projection with his hands of a dog barking and was like "oh, you mean this projection?" 

Two things I'm curious about but never figured out:

• Is it possible to control the order projections get called in (particularly when inherited)? I have a feeling they're alphabetical, but not quite sure..
• Aside from the ability to run a projection on class deletion, is there any difference between a projection and a generator method that just runs some code on compile and doesn't actually generate anything?