This didn’t make much sense to me, but I’m a noob so I wanted to ask. I thought the purpose of caching was to serve up the latest stored version of a previous call/request made on a database, so I figure maybe this was supposed to include the word “not” as in “will not be reflected in all results”? Unless I’m misunderstanding the purpose of caching the last 10 instances of BeanFactory?
Again, I’m a noob, so forgive me if I’m reading this wrong, but shouldn’t this be (see below) - because I think the default number of items returned per page is 20? So the -1 listed here corresponds to the $limit variable, saying return an unlimited number or all results, while a second -1 would correspond to the $max variable (so we’d have to put a 10 here or it would default to 20 if we left it empty or put a -1)?
The purpose of caching is to optimize performance of (potentially) repetitive data operations.
This might have down-sides - such as occasionally getting stale data. That’s why the warning is there in the Docs. Only peculiar use-cases (such as the ones that developers working outside the core tend to produce) will cause stale data to be retrieved. But if you understand what’s going on you can work around it.
Why do you say this? 
Thanks pgr - another question comes up then. My purposes for diving into the development side of suite is to build a custom call center app and suite will be the data management side of things - so the caching aspect would be both useful and something we could potentially have issues with. We plan to use twilio flex while operating individual suiteCRM instances for each client. My concern there is the potential for more than 1 agent to have a record open at a given time - though very rare (we could be talking something that happens 1 in a 1000 or even 10,000 CRUDs to the db) it could cause a similar type of conflict to what i’m reading about the BeanFactory? Would incorporating the AJAX functionality of suite help solve such an issue or cause new problems?
On the 20 item thing, I read this a section or two above Example 3.6 on the developer docs page for the Beans.
Ok, about the number 20 I think (though I am not 100% sure) what they mean is the setting that you can find in Admin / System Settings, Listview items per page.
About the caching, it’s not as fragile as you might have been led to believe. Just do your work normally as long as things behave as expected. Only if you run into strange problems, then you might have a look at this issue.
Usually all it takes to work around is some extra care when saving records, to ensure they invalidate the cached beans. But I think you will find this is already taken care of in most places, or even all.
AJAX has nothing to do with this.
1 Like