I just noticed that *LIST* objects do not have the...
# sdf
s
I just noticed that LIST objects do not have their (numeric) internal ids in the xml. Is there a way to specify the internal ids so that I can be sure a list matches id-by-id when deploying to another account?
this seems a rather glaring oversight, given that we use numeric ids for list values in SuiteScript. I have a situation where I have a list with ids like 1,2,3,5. I'm pretty sure when I deploy to prod that will become 1.2.3.4 and break any script that referred to value 5 for that last list item?
w
You can't set the internal ids for lists (or anything). I usually write a function to translate the scriptids to the internalid on execution using a search on the list. You could also use N/cache if this is fetched often in multiple executions.
s
egads
I definitely don't want to incur the complexity or resource hit of doing a search for these immutable values.
but I can understand you doing so as a way to compensate .
w
s
I've read before and for these essentially static lists the runtime burden of doing a list search and the additional complexity is unacceptable
w
Can't argue there. I would have liked it to be possible to refer to the records using scriptId. Since you cannot have installation scripts in sdf (I think), how about you programmatically edit a lib-file on the first run with the current environments ids?
s
these are all reasonable ideas if buiding a suiteapp In my case the only time this has been an issue is when working with an existing list that needs to change on both SB/prod for a given client.
I generally work on customizations not suiteapps. This issue makes me a bit thankful i'm not working on a suiteapp to be used on many accounts!