I realize this may be a controversial topic, but considering that we do not have any control over NetSuite DB and that includes DB structure, tables, relationship between tables etc. NetSuite can modify/update their DB structure or relationship between tables at any time without notice while they can also update the official API modules (N/query, etc). Why do I see so many people blindly relying on RAW SQL queries or using them in production? I’m missing something here?

What's the difference in relying on a published database schema and relying on a published JavaScript API?

Same with Saved Searches or Analytics, no?

The JavaScript API is officially supported by them, which means they can update underlaying structures and update the API Methods, in which case any code using the API continues to work while RAW queries can potentially break… that goes for the entire API, Object ENUM etc…

The implication there is that the database schema isn't officially supported?

The implication is that underlaying structure can change, are RAW PLSQL queries officially supported? I’m using SQL as an example, but is also true for: • result.getValue() vs accessing directly to the result object. • record.Type.SALES_ORDER vs

salesorder

And goes on…

I mean they can do this ... but why would they??

So the fear is that NetSuite will change the way e.g. Transactions relate to TransactionLines and that will break any raw queries but not any queries built with the JS API. That's a valid concern, but I don't think the analogy here is quite right

they're still supporting SS1.0 😄 I wouldn't lose any sleep over it.... if the question is why are ppl using RAW anything? what's the benefit of that? then I don't actually have a good answer, I see ppl do it, I'm not sure why

NetSuite introducing breaking changes to the database schema is the same as them changing the names of functions or options in the SuiteScript API. e.g.

record.getValue({ fieldId })

becomes

record.get({ id })

@erictgrubaugh I’m failing to see that, they can change the record structure and update the getValue method with an OR condition to consider both input types. The can change a search result object structure not to be (field[value1, text1] and update the method to retrieve the values from the new structure…

These don't feel like fair comparisons

Lets go back to the core then, It does not feel right to me to use SQL queries against a DB I don’t have any control over… this does not feel right with NetSuite or without NetSuite on the equation, specially if such database has defined API methods to interact with it…

NetSuite can modify/update their DB structure or relationship between tables at any time without notice

I'm not sure they can to be honest? like technically they literally can... but in any sort of real-world scenario... they really can't do this at all

To answer your question directly for my personal situation - Because I don't feel like it's a significant risk that NetSuite will change its underlying database structure.

The first time I saw NetSuite in 2016 it never crossed my mind that Oracle (or anyone) would pay 9 billion dollars for it… and yet, here we are…

For the same reason I don't fear that they will introduce breaking change in the SuiteScript API on a whim

I'd also point out that we're probably not querying raw tables anyway, we're likely querying views, so they can update their structure anytime they want and update the views accordingly knowing that their customers are relying on them.

also, if they change the underlying database structure, they also have to re-write at least part of NetSuite itself

@Taylor Boon It was also unlikely that they were going to remove jQuery and they did it…

I'm not sure what the valuation of NetSuite has to do with any of this? Nor what your impression of the company's value, based on ... the structure of the webapp instead of the company financials?

But they didn't do any of those things without notice

and also, i don't believe any of their JS code relied on jquery, so much easier to do, from NetSuite's perspective

@Anthony OConnor Not bringing the valuation of the company as something special, just to point the fact that drastic changes happens, acquisitions can come with even more drastic design changes… ask Twitter…

We can't write code that's perfectly inured against every possible disaster

but to you point of the negative impact... it would be huge, close to 100% of their installed customer base would have a disaster on their hands when all their customizations stopped working. it'd be corporate suicide

So we choose acceptable risks. For me, writing queries against NetSuite's published schema is an acceptable risk

But I can minimize it right? I can choose to only use a RAW query if I can’t get the data with the regular API right?

and for us? we'd get a bunch of work to fix the mess and see massive rate hikes for consulting due to huge demand increase

In the same way that I write JavaScript against NetSuite's published API

No no, I’m asking and debating, my question ends with: I’m missing something here?

I think the "controversial" part here is just how likely the risk is...i think we all agree the impact would be huge if NS did anything like this... but they have a track record of NOT doing this, there's no benefit to them doing it, and so the likelihood seems incredibly small to most of us, and therefore rounds to zero... it seems you estimate the likelihood higher than that so you want to mitigate against that, I guess that's your choice

My question is for debate and to see different points of view…

You're not missing anything, I don't think. Anthony nailed it; we're assessing the impact the same but the risk differently. There's nothing wrong with either assessment. One of the universal constants of building on someone else's platform is that you accept the risk that they will be good stewards of said platform.

I think if there was a significant risk, NetSuite wouldn't allow it in the first place.

^^ Oh, you mean like using EXT JS? ahem. 🤭netsuite😉