https://netsuiteprofessionals.com logo
Join Slack
Powered by
What's the best way to search through a dataset (s...
# suitescript
c
What's the best way to search through a dataset (search.ResultSet) without looping through the results?
m
I believe there is a getAllValues function you can call
c
message has been deleted
These seem to be the only functions available on the ResultSet
m
Its not documented, but it works 🙂
s
Lodash probably has a function that suits your needs
c
Lodash?
s
c
Not documented == may not work with upgrades etc?
s
Potentially not, risky maneuver to use undocumented fn
m
Netsuite themselves use it in examples for suitescript.
c
Another option is to do one search per line item on an order - line items length can be over 100 though
s
I'm telling you, just use lodash
c
With lodash I'm just looking for a function to get the results into a data structure that I can easily search?
s
Lodash is a very commonly used js library, it has tons of functionality.
c
yeah, that makes it tough the first time you look at it
I'm trying to figure out what it can do for this scenario
s
It's very intuitive, and documentation is good
c
DO I really need an external library for this?
s
Check that function, for example, no reason to re-invent the wheel. It's worth (long term) to be comfortable using/implementing lodash
c
how painful
b
you dont, but it makes it nicer
you would probably be doing an equivalent to https://lodash.com/docs/4.17.15#keyBy
c
The NS doc doesn't specify which data structure the ResultSet is
I guess array or obj
b
you would need to use getRange or each to turn it into an array of search results
c
so with lodash I would just do
let searchString = $whatever$
_.find(ResultSet, {'location', searchString})
and that would take my lineItem (searchString) and find the matching value in the ResultSet?
b
no
c
yeah thought not
b
ResultSets arent that friendly
have to use the normal ResultSet methods to turn it into an array of search results first
c
so the only option is each() or getRange() by the looks of it
b
yes
s
Most likely run the search, and toJSON() the results, then use library to look through them.
c
each() is a loop so will hammer governance
b
as you might expect, the ideal way is to search for all your search results in one search
s
^
c
so I could get all the line items then do a search with ANYOF filter
loop through the lines and place each one into an array
then pass the array to the search
s
Yes something like that is what I would always recommened
b
keep in mind that you will have to find the matching search result for each of your line items
c
yeah, and deal with duplicate line items
b
keyBy will create an object where the keys are whatever key you choose (likely item internal ids if you are working on a transaction like sales order) and the value is the search result that matches that key
its not terribly difficult to write the keyBy function yourself if you fear lodash, nor is it hard to write find
s
a big reason (imho) to use something like lodash is the code has likely infinitely more unit tests than ad-hoc code, and it's certainly been real-world tested far more than any ad-hoc code written in a script.
s
Yep and its really easy for someone to come along and understand the purpose
s
that's another great point - these methods in lodash are well known names. And they are well documented. In my experience none of these 4 or 5 facts are true of handwritten ad-hoc solutions. Personally, I'd go so far as to say NOT using a library such as lodash is irresponsible for professional software developers. There, I said it. 🙂
c
I sort of agree
but I don't see this used in NS PS work / scripts
and need to stick to standard where possible
lodash adds overhead on understanding something that could be simply done with one search and one loop
I can go through the line items then do indexOf against the search results. Just need to approach the problem from the right angle
s
NS PS is a least-common-denominator approach, not 'standard' or 'best practice' in my opinion.
c
Agree
Quick update - I finished this using the most generic and simple JS I could write and using no external deps
the journal items are copied into a new array and passed into the search, the search result loop has an inner loop to match against the location in the JOURNAL record, everytime a match is found it updates the line department field then removes that line from the array so the same line is not looked at twice, this avoids hitting governance limits.
Open in Slack
PreviousNext
Powered by