Clearing cached DB schema on running app

[adamcameron]

Howdy
Had a read through this: https://guides.cfwheels.org/2.5.0/handling-requests-with-controllers/caching. Lots of info on caching stuff. Didn't spot anything about clearing said caches?

We had a situation today where we dropped a disused column from a CFWheels-"modelled" table, and our app went splat because CFWheels caches the DB schema as part of its modelling. Something I had forgotten. Easily "fixed" via re-adding the column hastily, and swearing a lot (possibly the former was actually the fix; the latter was just cathartic).

However. We still need to drop this column, with minimal downtime to the users. We're OK to go into maintenance mode for a few sec whilst we do it. I'm guessing it's application-scoped caching so just restarting Lucee will clear it... is that the most expedient approach? Is there a CFWheels-idiomatic way of doing it? I have found the CFWheels app-reload process to be... problematic, so that is off the table.

We are on 1.4.5-ish (which, I know, does not do us any favours either, but it is what it is).

Am I kinda best just running with the restart-Lucee approach?

Cheers for any insight.

--
Adam

PS: whatever the idiomatic answer is... might be a good idea to update that caching page in the docs to reflect it.

[bpamiri]

Adam,

I typically use the app-reload but since that is off the table for you, do you have multiple servers in production behind a load balancer by any chance? If so, you could take a server out of the load balancer and restart it and put it back in and repeat for other servers. This would potentially cause no down time for your users. If that's not an option either, then perhaps an after hours restart of Lucee is the only way to go.

We could potentially find the structure that gets set during initialization and try to delete the structure and rebuild it behind the frameworks back but I would suspect that might cause even more issues for users that hit the site while this cache popping is happening. I'll see if there is a better way to do this and perhaps exposing functions to rebuild the internal caching structures would be a good idea.

For what it's worth, we've standardized on db migrations for all database changes. This way we can commit db changes to source control. I then use a Jenkins process to push code to my production servers and then issue an app reload on each individual server. By adding the set(autoMigrateDatabase="true"); to the config/production/settings.cfm file, our migrations are automatically run when the app reloads. Lastly, the Jenkins job is automatically run when a commit is made to the repo. So the whole process gets kicked off with a commit to the repo and at the end of it each of the servers is reloaded and migrations are all run. I realize this may not work for everyone but I thought I share just in case it is of interest to anyone.

-Peter

[adamcameron]

Hi Peter
Yeah, we have the apps traffic-managed, but this is no help in this situation as the DB is not traffic-managed. So all the app containers break when we drop the column.

Re CFWHeels's reload thing. I have never been able to track down the cause, but under any sort of load, CFWheels's reload functionality breaks stuff as there seems to be some sort of race condition going on that makes assumptions above whether application-scoped variables need to be reinited. The thing is that it all happens in onApplicationStart which should be single-threaded and only one request should ever run it for the life of a given application, but at least on Lucee this does not always seem to be the case. Am pretty sure it's not a CFWheels problem. Try as I might I could not reproduce it, so have not raised it either with CFWheels or Lucee. Also as I said we're stuck on 1.4.x, so no point bugging all y'alls about woes we have there.

Re DB migrations: yes, in our new platform (Symfony on PHP) we do that. Never did on the legacy CFWheels app (which is in maintenance mode now). Not sure this would be helpful / relevant in this situation anyhow.

Cheers for the feedback: all good info. We've got a plan that will only require about 2min of "maintenance mode", so not the end of the world.