Is “Rank” not a supported aggregate function in su...
# suiteql
c
Is “Rank” not a supported aggregate function in suiteql? I just get the error “Invalid or unsupported search”
c
RANK and DENSE_RANK are both supported. It's probably mad at how you are trying to use it. Share your query?
c
Here is a basic one that should work I would think: select RANK(id), id from customer group by id
Or even: select RANK(1) does not work
Bleh nevermind I think I found the correct syntax RANK() OVER(ORDER BY id)
c
Yep! That looks more like it 😁
s
it scares me to imagine y'all writing complex queries due to suiteql. Talk about hard to debug code 😕
c
Don't worry about us @stalbert, the Netsuite error messages are SO HELPFUL
🤣 2
😄
s
sorry, I've always been a bit biased against complex SQL in code because there's generally little to no help from the main programming language or debugging tools. It's just a bunch of ad-hoc text that is actually database programming in disguise :)
w
It's really convinient to replace several lines of code to join two searches and filter the result compared to writing at SuiteQL with all the joins.
👍 1
s
agreed, that's a good use of SuiteQL IMHO. It's these hundreds of lines long queries people talk about with all sorts of SQL functions involved doing lot of heavy lifting that make me sad, both for the people authoring them and the people that support them years down the road.
doing multiple or ad-hoc joins is a strong point of SuiteQL and hence makes a lot of sense to me over coding it up.
on the other hand, doing things in SQL that have better (easier to write and maintain) representation in TypeScript is troubling. I try to use code for what code is good at and sprinkle in SQL where SQL shines.
I say typescript above because of all the benefits strong typing brings that SuiteQL doesn't enjoy (at least not in the typical IDE)
c
Our team went all in on SuiteQL at first and crafted these lumbering behemoths of queries that would spit out exactly what we were looking for; that is, after sending Netsuite's servers into dozens of seconds of groaning, shuddering work, and the slightest change we'd need to make to our target result set would involve sacrifices I can't even admit to in a public forum. We've since come to a place of running as lean queries as possible for datasets we can slice, dice, and saute in SuiteScript after the fact. Developer sanity is much better for it 😁
🎯 1
💯 1
s
having libraries like
lodash
makes set based manipulation a lot easier in TS/JS, so that slicing and dicing in code can be quite succinct yet readable and testable.