so google doesn't have a relatively recent answer ...
# suitescript
r
so google doesn't have a relatively recent answer for this. If I want to store custom parameters accessible to every SuiteScript (like the default employee account to use for system generated email notifications), search results say it's either a static JSON object in the File Cabinet, or a single Custom Record with all your options. Custom Record would let privileged users at least change values when they want. Is there a any other better way the more experienced would recommend?
n
I think you can set global script parameters in the company settings.
I bet Anthony would know
😂 1
a
lots of options here so depends on your use case global params in company settings N/cache module and the previously mentioned singleton custom record and JSON file in FC
n
😏
a
they all have their pros and cons i guess
I think for simplicity the custom record is the best way to go, puts all the things in the same place and can be edit / reviewed easily in the UI without need to know code
r
from my searching, Company Paramters look like they can only be set from a Suite Bundle, which we're not there yet
a
i generally only reach for the cache module when its for a performance boosts, i.e. something I know I'm gonna be looking up 100s / 1000s of times no reason you can't do both though... make the custom record and then load the custom record once into the cache and use the cache so no additional record loads/lookups
r
the custom record with N/cache might not be a bad idea. Anytime that single custom record is saved, just trigger a new cache clear
a
...right aftersubit UEon the custom record to refresh cache
r
yea
a
👍 1
r
so this under the help has me concerned.
Important A cached value is not guaranteed to stay in the cache for the full duration of the
ttl
value. The
ttl
value represents the maximum time that the cached value may be stored. Cached data is not persistent, so you should consider using the Cache.get(options) method with the
options.loader
parameter to set and retrieve data.
If I can't guarantee a response, then I'd be writing my own loader function to read/write values from a file anyway unless I'm missing something
a
right you just set the loader up once like in your cache library
and if you get nothing back from the cache it calls the loader
its kinda like a try catch, once you've done it once its not scary at all... and unless you're account is crazy its never really an issue tbh
r
I hope our account never gets to that point. clean & lean code is #2 for my work.
a
no really about the code so much but how aggressively you're using caches i think?
honestly i dont knwo what causes NS to force clear it
but its never a concern, set up the loader, it calls it as needed, if you're calling it a lot then it WILL be fresh and pulled from cache and save you the roundtrip
r
thanks for the tips
a
no worries, you can setup the custom record and use that initially and implement the cache later as needed
e.g. i woudlnt bother with the cache when doing a proof of concept
r
I'll probably end up doing a file method anyway instead of custom record, but I can still use N/cache from the file. Reason for file is that I want params to stay when refreshing sandbox.
z
No, you can create Company Parameters... But the way is funny 😁 Create a dummy script (any kind) and for that script create parameters... One option for script parameter is context, and there you can say COMPANY 😁😁😁