JavaScript for SQL?
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
jschell wrote:
reduce latencies, network overhead, and egress costs
Definitely a worthwhile goal.
jschell wrote:
Same thing SQL already does.
SQL Server? I use a lot of CLR (C#) functions in SQL Server for various parsing and formatting purposes which are not built-in.
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
Aside from other's responses I'll add that given what I found out about JS limitations trying to do hashing and value equality semantics it's surprising that they'd choose JS of all languages to augment DB ops. I don't agree with any of it. Render unto SQL that which is SQL is my view. But say I did - JS wouldn't be the first language I'd choose to implement. Which brings me back to the crux of my comment the other day about JS, and how it's being used in many more places than it's ready for.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
-
Now watch your SQL server implode because someone's starting to drag in dozens hundreds thousands of dependency libraries to perform some trivial task...
It's up there with "code behind" and "breaking" the MVVM model. Or using C# "custom code" in LINQ .Where() clauses. (Which I do all the time ... and love).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
It's up there with "code behind" and "breaking" the MVVM model. Or using C# "custom code" in LINQ .Where() clauses. (Which I do all the time ... and love).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Aside from other's responses I'll add that given what I found out about JS limitations trying to do hashing and value equality semantics it's surprising that they'd choose JS of all languages to augment DB ops. I don't agree with any of it. Render unto SQL that which is SQL is my view. But say I did - JS wouldn't be the first language I'd choose to implement. Which brings me back to the crux of my comment the other day about JS, and how it's being used in many more places than it's ready for.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
Render unto SQL that which is SQL
For certain. No one language is the best at everything, but SQL is the best at what it does.
-
From CP newsletter https://www.infoq.com/news/2024/01/mysql-javascript-procedures/[^] MySQL (Oracle) is going to add JavaScript. So instead of using SQL. The article has this bit of sage advice... "enables developers to implement advanced data processing logic within the database. By minimizing data movement between the database server and client applications, stored functions and procedures can reduce latencies, network overhead, and egress costs" That seems familiar ... hmmm ... Oh! I know! Same thing SQL already does. Except that SQL is actually optimized to use the database. This is no different really than moving a JavaScript server into the MySQL application space. Oh sigh it gets even better. One suggestion... "data formatting," Because of course that is the best place to format the data to be human readable. But there is some relief - yeah! "there is no support in the MySQL Community Edition." The article does seem to suggest that the procs might be directly replaceable with the equivalent SQL. At least if they have enough sense initially to not make the database do what some other application should be doing instead. Makes me wonder how many places that pay for Oracle the licensing fees are going to have employees that using JavaScript is going to be a good idea? I doubt DBAs are going to jump on this.
But will it run DoomTM?
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
Now watch your SQL server implode because someone's starting to drag in dozens hundreds thousands of dependency libraries to perform some trivial task...
-
lol Didn't even consider that. Other post mentions C# used in SQL Server (which I had forgotten) which has a similar problem.
jschell wrote:
Didn't even consider that.
You know that's exactly how JavaScript "developers" will abuse it. If they have to make SQL usable with JS, it's because those JS developers lack, shall we say, the sophistication to use the tools that already exist and are better suited for the job. And if they don't have that sophistication, you know they ARE going to perpetuate the same mistakes they're already making.