can someone explain when flushAtRequestEnd=true is a good idea!
I think the line of thought is that there is no database (or spoon). Only model objects which are self-persisting and that’s all you need to know. You put whatever data you need in your model and it will remember it. It’s not your job to think about how and when your data gets persisted, your persistence layer will handle that, thank you very much, now please go back to writing business layer code. A proponent of auto-flushing would probably ask you “why did you put data in your model that you didn’t want there?”
Not saying I subscribe to any of that… just saying that’s my understanding of the concept. That being said, I’ve sort of gotten the impression that most people who really get into ORM still want more control over what gets flushed and when.
~Brad
Especially when you want to do validation, I know this thought came up many times during the initial discussions on it.
And most at the time, and I disagreed then and still do.
But they figured like Brad has outlined, but that means that any time you need to validate your data you need to create a non persistent copy first then do your population and then validation and then persist it. Which meant loading an entity, making it non persistent, do what you had to do, validate it and the re-persist it again.
Which would also mean you technically don’t ever need to call the save method either, because it just happens anyway. Personally I like to write the least amount of code that will do the job, and found that the line of thinking that it should just be persisted to be wrong, but that was just my thinking.
And as the very vast majority would need to have this not flushed at the end of the request kinda defeats the purpose of making it a default. So the answer was to instead of changing what should be logical, was to add a setting that enabled you to take full control.
Hence the setting in Application.cfc to switch it off.