So, my name is Mitri Lenio, I'm working for Perkona and I'm going to talk about open
souls support for routines in JavaScript, Interconne server.
And if you work about me, I'm working and I have been working in my school
ecosystem since 2003, participated in development of such things as storage routines in
my school, triggers support with new data dictionary in my school and now there's a
work for Perkona and particularly I'm busy with JavaScript support project.
Okay, so let's start.
So, what's the background?
The ground is pretty simple, Oracle started to support storage programs in JavaScript recently
in my school server.
It became generally available in my school 9-year-old and it's available in innovation
releases on the so far, but I'm sure it become available in some altias release later
as well.
There is a GoChainHour, the GoChainSPritus simple, it's either enterprise on the
future or a cloud on it, so you can't have this JavaScript routines in the community
version of my school.
So Perkona decided to provide an alternative solution which is free and open souls and we
are working on it right now.
So, okay, and there is this thing with JavaScript with Versus Js, as you probably know,
JavaScript as a trademark by Oracle, so I will try to avoid this use, use, using it.
So why do we want programs stored programs in some other language when stored program
language will already have in my school?
Well, if you try to write stored programs in my school stored program language, you
probably are not very happy, person.
It's fairly data-tling which, and let us be honest, it's not a by spread language, so there
are not that much people out where who know it by heart.
So it's a bit hard to find people who are ready to work with it right away, and let's
it, and also there is performance issues as well.
But if JavaScript is, and or yes, it's very different, it's a fairly modern language with
many features, it has array support and like some other language, it's language which
people do really know, right?
I think it's maybe a bit less popular during last few years because of AI stuff and maybe
Python, or take it.
Nowadays, but still according to Stack Overflow survey, at least 62% of developers
written something professionally in JavaScript during the past year.
It's quite an adoption.
Lots of people writing in it, lots of code out there in JavaScript, so lots of possibilities
for code reuse, right?
It's the second most popular language on GitHub of the Python.
It has millions of packages, which are ready in NPM Registry, lots of tools for developers,
and finally JavaScript thinks to its use and browsers, and in Node.js, it's fairly optimized,
so we have JavaScript tangents, which provide really nice performance.
For example, we did a small benchmark with our implementation and compared a simple function,
it's basically function which does data masking.
We implemented the same function in JavaScript, we had an implementation as a data
masking QDF in C, and we also implemented it in the same way in the MySQL story
tricky language.
The difference was quite significant, so JavaScript was 100 times faster than the SQL,
like the story procedure language, and UDF's was still faster, it's C, but only 10 times
when JavaScript.
And the mileage might vary if you're just, for example, running SQL from your JavaScript,
probably the difference will be less pronounced, on the other hand, if you do some computations,
which are supported well by JavaScript, the difference might be much more pronounced.
These were basically a string manipulation functions, okay.
So what did we do?
Actually, when Oracle has implemented JavaScript support, it implemented it as a component,
so we have a component API, and support for a server to call a component to process
routine in some external language, and we also have an API for such components, implementing
the external language, to get additional information about routine, to get parameters,
and overall we actually have this component API, which allow to do certain things in the core of a server.
Like find out if connection was killed, run purely in the column connection and so on.
So we basically implemented such a component.
One great thing about implementing external story routine, language as a component,
is that component should be enabled to work.
So if you do not use with feature, you do not enable with component,
and you do not take any risks related to allowing executing code, say, in JavaScript.
We use Google V8 engine for execution of a JavaScript.
It's used by Chrome.
It's used by Node.js, PLV8, use it.
As far as I know, upstream use as a growl VM, which are their own engine for JavaScript execution.
But V8 is much more widespread.
And honestly, it has much better documentation about how you can embed it in your program.
In this case, it's our component.
Overall, the picture looks like this, so we have SQL Core, which has parser optimizer,
data dictionary, data logging, subsystem, what not.
We have storage engines here, below the SQL Core,
and then we have service API, or component API.
And then, which interacts with component, which manages JavaScript code,
does some type conversions, provide some helper UGFs,
so additional data is visible and accessible from the inside of SQL Core,
and from mySQL.
And basically what it does, it's ropes around the V8 library,
which we use for JavaScript execution.
And then V8 library has a such concept like a NizoLate,
which is, you can say it's more or less a separate instance of V8 library,
in which your data is stored, and your code is run,
so each isolated is more or less isolated from each hour.
You can't really easily pass, for example, memory from my NizoLate,
so we use a isolated connection model.
And if you have read the Oracle, Oracle's white papers about how we do
support JavaScript, you may have seen pretty similar picture there,
but it's no wonder because ultimately both hours component
and various component are just a glue code between SQL Core
and some JavaScript engine.
And now in V8 it's V8, in V8, in V8, case it's柚.
So, we support both functions and procedures,
but not events are triggers, the same is upstream.
Again, in out, in out parameters are supported for stored routines.
We also support almost all SQL types as parameters or return values.
I think we actually support more than Oracle.
In this respect, we support parameters and return values and all character sets.
Yes, internally JavaScript is totally UTIF8 and before.
Well, UTIF8, but we do conversion for you.
So, if you, for some reason, still do not use UTIF8, you still can write a routine and avoid using some additional code to do conversions.
Then, according to JavaScript, you know, okay.
We convert blobs to array, buffer objects, so you can manipulate with binary data in JavaScript easily.
When I think of it's it, the level of GS language we support is the same as the recent stable V8 support.
So, let's make sure since we rely on it.
We have, although standard operators, data types, standard objects.
For example, math object functions.
We, of course, do not have any browser specific things, right, because we like DOM.
We are provided by browser and an SQL server is simply do not have DOM.
No point in it.
We are also one design decision which you made.
We are implementing a trusted language, which means that you are not supposed to be allowed to do anything from your JavaScript routine,
which you cannot normally do from the SQL.
We do not really allow any file access on it.
Work access, for example, for example, we are available in Node, right.
But we do not allow that.
We might change that in the future, but we are a security trade-offs here, so it's worth thinking hard about it.
So, that's a pretty simple example.
If you haven't, especially maybe useful, if you haven't seen how JavaScript routines created in Oracle MySQL before,
you just write create function, you specify language.
One difference here is that in upstream the name of the language is JavaScript, we do not use this name.
We use JS, as I have said, legal issues.
And also, to be honest, it's nice when you have a support ticket and you can tell right away if it's something from the upstream or from on someone you see your component.
Then there is this double-dore coating, which allows you to provide the text over JavaScript code after that.
And you end up closing with double door as well.
A mask-all command line client has support for this.
A nice support for this double-dore coating.
So you do not need to use this millimeter command.
If it, as you can see, they're variable, the parameter for routine is available,
just as usual JavaScript variable inside of JavaScript code.
And you can use it.
When you just use it like a normal story function,
if you will have time, we will do a bit small demo at the end.
So what's the current statusal project?
It's in the public page preview.
It's a separate branch of Percona server based on eight-four LTS.
Code is available on GitHub.
We do not have binaries yet,
but we do plan to have in this quarter.
It's quite possible to build it yourself.
Actually, in my opinion, the main complication is building V8, actually, where.
And the build instructions are available in the company's Redmi, MG file.
You can try it.
Yes?
I also plan in other languages.
It's a good question. Maybe at some point.
But there are quite some work to do with JavaScript.
Actually, let me show you in the next slide.
So what's available now in V3?
The support story program creation, dropping and execution.
We do all these type conditions, which I mentioned.
We support some advanced error.
I think you can get, for example, a stack for your latest error in the JavaScript code.
It works with, you can kill JavaScript procedure like a normal SQL statement,
a max execution timeout, works as well.
What we plan to work in the nearest future,
and actually have a internal prototype in which it works,
but probably not of the same quality as what we available already.
In GitHub, it's that console support, support for memory limits,
and support for execution of SQL from your story program.
So if we talk about differences between percolors, variant and upstream,
the main difference is actually license.
So percolors, one is free and open source,
and upstream the implementation is enterprise of cloud only,
and of course source is not available.
I think it's self-actual is open source.
And this way, I wasn't surprised if you did VA.
But documentation.
You should ask the code, and I don't think they were here at the Java future,
but if they are not yours or to other languages,
we have support for other languages.
Okay.
And you can ask the guys from canonical.
They provide shell without the people to pay them.
I don't request all of them.
When you push that, and you're leaving as well,
it's really a pain.
Yeah, well, we build it.
And actually, our build people are complaining about it.
But that's certainly doable.
I will talk actually a bit more about it, because how much then?
You still have to touch these.
Okay, fine.
So, other differences that what upstream has it is,
is 9x based, and what we have is going to be based on 8x4.
We are not aiming for full compatibility,
and I do not think it's really realistic,
but we tried to be at least on par, feature wise.
We have stream.
There are slight difference in syntax.
Language name is different.
There's JavaScript.
Some different option names.
We have different parameter conversion rules,
but that might actually be adjusted.
We have more.
Well, we have different auxiliary users.
If you have looked at the upstream implementation,
I think one or two,
UDF's which do everything.
Get the error lock,
get the console lock,
get the latest errors, something like that,
and that's it.
We split one into different UDF's.
We also have one differences that there are between implementations
between handle JavaScript context differently.
I think upstream has JavaScript context for each call,
which for us,
it turned to be rather expensive,
so we opted for JavaScript context for connection, actually.
Not exactly for connection,
but for each user, which executed in connection,
you can have several users, actually.
Active around the same time,
and things to sweet story routines or views of our functionality.
And we are catching up.
And of course, we are still in public preview,
so it's both a bad thing,
and the good thing is that we probably less polish it
when upstream, but on the other hand,
we still have a place for involvement,
and still are willing to do changes.
So, challenges.
Let me find a bit about both upstream and V8, actually.
So, there are some changes related to upstream,
which we encountered by developing with component.
First one is that we didn't find some services.
We needed in the upstream, one of them, for example,
was for notifying component about what connection is killed.
Yes, you can easily from the component,
find out with, okay,
this connection is killed or the current connection is killed,
but there is no hook, which would be killed,
called on the kill itself.
And it's not always convenient.
For example, for V8, it's not convenient,
for Gralve, I'm with my different story.
We found some bugs in the service implementations.
We didn't manage to report them,
because they actually will fix it in later releases.
But at least during work on the prototype,
we had some questions, and we had to investigate and fix.
For ourselves.
So, to solve these changes,
we had to extend a skull core a bit,
and also fix a bug.
I think we had the couple of services.
What happens to the context when we do switch user?
You just use different contexts,
and actually you also use different.
You just use different.
Yeah, we actually use different easily, even.
So, from security standpoint,
you cannot really pass any objects from one user to another,
unless you do it,
and do it, means explicitly, through routine parameters, for example.
Just have curious, right?
And what, how does it know that it's that,
the raw changes are, or you,
you are really, you are creating the new context from the first and last changes?
Uh, essentially, when, uh,
user, well, connection enters JavaScript,
which, in VCheck, and the VCheck user,
it is executed.
And if it's a new user, we create a new context.
And there are also some changes related to V8.
Uh, well, all of them, I would say,
are related to the fact that the primary user of V8 is raw.
So, we are very, very, very,
raw oriented.
Uh, we have this idea, is that,
okay, people will be running,
where JavaScript could probably separate process.
Uh, and if, for example,
we run out of memory, we will just crash the process.
And people will, people will restart the working process,
no problem.
Obviously, that doesn't work well.
So, we have to do some work grounds where,
we tend to break things quite often.
Uh, but they fix it on the other hand,
but still, you find it, you,
during the development of something is break,
and you need to either to regard to adapt.
And, uh, well, I guess the main problem is that,
we also do not really follow with a stable model,
uh, versioning model, right?
When you have a minor versions, major versions,
they do changes, using different considerations.
Uh, okay, so, how can you help?
Uh, please provide your feedback,
especially if you are JavaScript developer,
uh, because, uh, we,
I personally do not have much expertise in JavaScript, for example.
Uh,
bug reports are welcome, uh,
some feature requests are welcome, uh,
documentation and proven surveillance are welcome.
Uh, it's really easier to change things now
in, uh, at the public previous stage when it,
after it will become J, uh,
we also set the hours on GitHub.
Uh,
so that's pretty much,
cheat from the talk,
and, uh, if we have, like, five minutes,
we can,
but, uh, two or three minutes here.
Okay, so we can have a small demo against,
how it works.
Uh, so let's, uh,
per corner server,
just started up,
uh, it's compiled with components we have,
and they have some,
scripted, uh,
statements here,
so first we need to install component,
and when grant, uh, with special privileges,
uh,
okay, okay.
Uh, special privilege to root user,
so he can be, so he can create, uh,
root in JavaScript,
as you can see for seats,
uh,
then we can create, for example,
a simple JavaScript function,
which will use the standard, uh,
JavaScript muff,
library.
So, here we create function,
this is where, uh,
JavaScript code, uh,
muff with standard JavaScript,
object, uh,
silzy,
32 is one of the standard functions,
which find, uh,
I think it's,
left must use bit,
something like that,
and here we just,
essentially provide the broader,
around the standard JavaScript functionality.
Uh, a bit more complex,
example is, uh,
maybe this,
uh,
it doesn't fit.
Okay, let us skip it.
Uh,
so I also wanted to show,
uh,
the error reporting mechanism.
So, you have some perhaps not,
not very sensible JavaScript code here,
which contains an error,
you try to run it,
uh,
it returns an error to you,
and you wonder what exactly happens,
so you call,
you give,
which, uh,
gives you extended context about error,
uh,
and essentially,
shows the stack trace,
where the error happened,
and, uh,
it's,
actually,
shows exactly,
positioning the code,
the,
where it's,
has happened.
Uh,
but it's pretty much it,
so we demo,
so if you have questions,
yeah,
you mentioned there is no,
five system access,
but you also mentioned at the end,
libraries,
how do you bring in there?
Uh, that's a very good question.
Uh,
probably like,
uh,
in nine,
four,
is it nine,
four,
which was most recently released,
essentially,
in the,
in the latest,
in,
uh, libraries,
uh,
so one can,
at library,
yeah,
uh,
you do not really,
you know,
import existing,
a library,
a formal five system,
in the very case,
you create,
create model,
create library statements,
something like that.
Essentially,
you,
you create library,
provide its body,
and then the component can use it as a library.
But yes,
it's actually one of,
uh,
to do things,
which we have.
I'm not sure we will go with that,
the very upstream,
has gone,
because,
uh,
we have changed that dictionary for,
to support it,
and,
uh,
we probably would like to avoid it,
but,
we should see.
Yes,
there's no way to,
sorry,
but,
uh,
what is your,
uh,
over and over,
well,
if you do not use any JavaScript function,
you do not,
because,
you say that,
you,
you call a JavaScript code,
okay,
under the new yours,
user,
in connection.
So if you do not call a JavaScript code,
nothing happens.
So it's,
uh,
from this point of view,
and if you do not use JavaScript,
you don't have to enable the continent,
in the ultimate case.
Ah, yes,
yes,
um,
there is no way to black,
I can solve it, right?
Really?
A JavaScript console,
is,
is there a way to,
to have a string of the,
you know,
if you do a console,
but,
you know,
if you do a console,
but,
you know,
uh,
is there a way to,
to connect,
and that is dreaming,
if,
which gives you the access to whatever was printed to JavaScript console.
Um,
it's not a console,
it's,
uh,
it's a separate thing,
but,
it's pretty much similar,
you just do,
select and,
and so on.
Uh,
I think,
in the first version,
which we will have,
in the test preview,
it will be,
uh,
all the same,
so it's,
to give you,
which will give you access to the console contents,
uh,
but,
I,
I was thinking about supporting,
like,
or,
pieces.
It's,
it's not even
connection with kill,
but the Java script execution
in the connection.
So what's,
what's,
what's the execution of your webboarded,
but,
connection won't be killed itself,
you can,
or use the connection in,
yeah.
Okay.
Good had a good day together.