Question about SS 2.1 Map/Reduce scripts: Is it n...
# suitescript
s
Question about SS 2.1 Map/Reduce scripts: Is it not possible to return a saved search from the getInputData function/stage? I have tried three different fully functional 2.0 scripts which all return a saved search from GID, but there are no key/values passed to the map or reduce phases when I change them to 2.1 (no other changes to the code). However, if I return an object or an array, the 2.1 script will pass the key-values to the map and reduce phases. Is this a known limitation or a bug?
n
I had the same issue, haven't had time to debug it further but as someone suggested you should try to check the summarize stage for potential information about the other stages, I've been meaning to but haven't had time 😕
But it feels like a bug yeah..
s
Thanks, I'll see if the get input summary has any errors in it
a
@suitedev This is why I don't like to pass search OBJECTS from
getInputData
... remember we had this conversation... any MR script with 2.x will break or stop working if NetSuite does not fix this.
s
I always try to return the search object from getInputData so that NS can do whatever it wants to optimize things.
It's shocking to hear that is somehow broken in 2.1
a
@stalbert The problem with that is ONE day NetSuite may decide to change the underlying object structure and update getValue(or any other method), any MR accessing directly to search objects will break but the ones using the regular/standard methods would not.
s
the 'standard method' is to return a search object
in fact, I think it's more likely they will break something about the custom objects you might otherwise return from getInputData
if they change what a search object looks like, it's on NS to support it - it's a clean abstraction.
a
Sorry I don't think accessing object.name.value is standard compare to getValue(name)
s
I'm referring to returning a NetSuite defined object type (the search type) from getInputData vs. returning arbitrary javascript objects defined by us.
b
@alien4u point is that returning a search in getInputData is the same as relying on result.toJSON remaining consistent since that is what NetSuite uses to stringify search results
a
@stalbert When you return a search object from getInputData you cant use getValue or getText in the next stage, making that an static object kind of object.name.[0].value or something like that, I think that is worse than using getValue in getInput and return your actual search results.
b
vs what he advocates, which is running the search and then returning whatever object you want
a
Because again I dont trust NetSuite enough to think they will never change the underlying static object structure... Which is kind of what is happening here with 2.1 MR, this is just event worse because they are not passing the object at all.
b
its more that the getInputData stage fails. map stages and reduce stages are never entered
the terrible thing here is that the inputSummary has no error in it, so its harder to see how it failed
s
@alien4u how do you use
.getValue
in a map stage of results passed from getInput? The data comes stringified, it has none of the properties any more?
a
@Sandii You can't. that is my point...
s
Oh ok I read that wrong then
i thought
cant
said
can
There are legitimate reasons to return a search.create from the getInput. For example, when getting very large amounts of data, you cant run the search anywhere except getInput, and ive seen a specific example where it times out trying to run it anywhere else
a
@Sandii I also faced those time outs, however 9 out of 10 cases are searches not well optimized or results not narrow down properly I will do use and return the search object in those cases only as a last resort.
s
Yeah it's pretty uncomfortable having your search take that long anyway and hoping the getInput always works
s
I agree with you @alien4u that the way results come into map/reduce is lame
👍🏼 1