How is anyone handling changing function signatures with a large number of entities? Having to call ormReload() is taking ~5 seconds which really slows down development every time a function body changes. I've resorted to moving functions to another CFC and then I inject the functions dynamically at run time.

My strategy for handling development process like this that might take time, is to just have a development only endpoint URL I can hit to re-initialize. I do this for things like reloading my DI/1, since the number of components we have is so large that reloading on every page request is too expensive. If you already have some build scripts in play (gulp, ANT, whatever) that monitor folders for changes, you can even have the endpoint called automatically to reload the configuration.

Yeah I have the endpoints to reinit. But annoying part is say when writing unit tests for new functionality. Adds a lot of time between every source code change and test run. Feedback cycle gets real slow

probably you need some design pattern - I think it's Strategy - if function behaviour changes in runtime

Typically we create entities using "new Entity()" rather than entityNew() - which picks up function changes. But I noticed entityLoad(), get_Relation_() doesn't get function body changes without a ormReload().

If your ORM components are separate in your folder organization (so that there's a parent folder that only contains ORM stuff), you could use a directory watch build tool to monitor that parent folder for changes and then re-init. While there still may be a delay before things are picked up, I've found this usually speeds things up. Plus, if your just reinit on every run of your test suite, it can save time so that the reload only occurs when needed (not when making changes to your tests).

@dswitzer Yeah I like the directory watching approach, I have done that before. Was a little tricky to lock and sync the server. There are weird errors if two ORMreloads() happen to get called before one finishes

@rory I use VSCode and for use cases like you have (where I don't really want to reload every change, because it causes issues) here's the worflow I have. It's unique to our dev environment, but there might be flows you can mimic. We use Vagrant for our dev environment (so we can all mimic the production server OS) and I have a bash script I can call which will reinitialize/reload the application. The bash script just calls cURL to a script which does things like reinits, clears cache, etc. Basically everything to get the application into a freshly initialized state. I have VSCode open a terminal window via SSH into our VM when opening the project. This gives me really quick access to the bash script to re-init. The script is usually the last one I've run, so it's very easy to trigger. So there is a little bit of wait while this happens, but this workflow is an exception to my normal flow and only happens in a few situations. So if your ORM components aren't usually changing a ton (except when actively working on them), maybe something like that will work for you if the directory watcher introduces too many issues.

this is where fusion reactor or lucee's advanced performance plugin by @zackster is very helpful.

How does the performance monitoring help in this case?