N/query allows you to return 5000 or do a runpaged...
# suitescript
s
N/query allows you to return 5000 or do a runpaged with a max of 1000. Is there a way to marry the 2 and do a runpaged where it pulls back 5k at a time? I have 300k results and I am trying to return back those 300k, with n/query, as quickly as possible
s
Don't believe so, 1000 per page is the way to go
👍🏼 1
b
do the opposite, use the ResultSet to get 5000 results at a time
add additional criteria to exclude the previous results in your query
s
Is it possible when loading an existing workbook?
b
you can get it pretty fast if you treat the internal id as a number
s
Ok, so I would need to load it and then add an additional criteria
b
yes
s
Would the additional effort be worth it in speed?
b
probably depends on the ratio of time spent on the query vs time spent transferring the column data
for my tests, i just use the id as the column and the result set with a condition runs in 60% the time of the paginated query
s
Do you have an example you'd be willing to send?
b
as in how to add a condition to a query?
s
Sure! I can look it up and play with it but I figured if you knew where an example was I would ask
b
in my lazy case, that condition was an id related condition using a comparison against the greatest id of all the results
my test makes the assumption that the results are sorted by id, so getting the greatest was the same as getting the last
s
Ah, yeah this one has a different sort than internal id which I just thought of. Not sure if that would work. Is there a way to say, run the search, grab me 0-4999 and then grab 5000-9999?
b
@tdietrich recommends nested queries to use rownum
it wasnt faster than a paged query, so i dont use it
s
Just looking at the lazy way you mentioned above, so if there are 300k results, do you have to have 300k conditions? Give me example of a are hard coded and there is no between or anything
b
one condition per resultset
so if there 300k results, thats 60 different conditions
s
Oof. So you'd have to know the internal IDs and the order pretty much. and if there are 300k results in query, the first could have 0 and the last could be 900000
b
as an example, if the first result sets greatest internal id was 5712, than the second id filter would be id greater than 5712
you dont need to know the internal id or ordering in advance, only that its sorted
you use the results from the previous result set to determine the condition for the next
s
True. Man, would be a lot simpler if they'd just let you pull more than 5000 or 1000 at a time
d
can't you just do something like this?
Copy code
function getAllQueryResults(rootQuery) {
	var pagedData = rootQuery.runPaged({ pageSize : 1000 });

	var queryData = [];
	for (var i = 0; i < pagedData.pageRanges.length; i++) {
		var currentPage = pagedData.fetch({ index : i });
		var currentPagedData = currentPage.data;
		
		var results = currentPagedData.results;
		for (var j = 0; j < results.length; j++) {
			queryData.push(results[j].asMap());
		}
	}

	return queryData;
}
s
Yeah, that's basically what I did. I was hoping to get larger than the 1000 page limit, because doing that pull 300 times vs 1 time or 10 times is going to take a lot longer
👍 1