https://netsuiteprofessionals.com logo
Join Slack
Powered by
Quick Survey for `Map/Reduce > getInputData()` ...
# suitescript
s
Quick Survey for 
Map/Reduce > getInputData()
In practice, do typically return a Search Object to MAP, or do you prefer to run the search and return the values?
I like to return the Search Object when it's feasible, but I noticed recently that property names for JOINs are reversed.. 
Field.joinField is returned as joinField.Field
-- Having to keep track of column names in the MAP phase is cumbersome.. I'm leaning toward only returning the Object when I have a simple result set, like result.id.
k
Mostly i always return just the object as the search does mostly what i want. but i have recently had to return custom keys and values.
👍🏼 1
e
If one search result is sufficient, I just return the search results. But if there are other joins that I need that are not handled in a search, then I return the mashed up JSON object.
j
I prefer to run the search and return my own values, which gives control and certainty about what to expect in the later stages
👍 1
s
I prefer to return the search, and then in the Map or Reduce phase I parse the context.value(s) back into something more similar to a real search result with some utility functions. It makes dealing with joins and summary results much easier.
👍🏼 1
e
If there is a large result set, I generally return the 
Search
so I don't have to build the paging myself
I nearly always use a 
map
stage to transform the 
Result
into something more digestible though
👍🏼 2
a
same as eric & scott for me, return the search and manipulate it in map or reduce to a better structure if needed
👍🏼 2
s
I return the native search object whenever possible.
👍🏼 1
a
@erictgrubaugh @suitedev @scottvonduhn Maybe I'm missing something here but if you pass the result object, you can't use standard API search methods like 
getValue
in the map stage, do you?
s
NS returns the values in an Object.
{
recordType:'invoice',
id: 123,
values:{
subsidiary:{
value: 123,
text: 'subsidiary 1'
}
}
}
standard text/number fields contain their values.
k
Context.values.subsidiary.value
That is what I would do anyway.
a
This is why I don't like doing that, I don't trust NetSuite enough to think they will keep the same structure. The can change the underlying structure at any time and update the getValue, getText methos and your code will break, while any other code using standard API methods will continue to work...
👌 1
👍🏼 1
👍 1
s
@alien4u The joins are a little funky, but otherwise, I don't think they'll change it.. it's definitely healthy to have some skepticism though!
a
@suitedev Not only joins, formulas are also a nightmare in that way...
s
and grouped results 😄
a
If you want to play safe, I will use standard methods and then I don't need to worry about that ever again...
s
true
Open in Slack
PreviousNext
Powered by