|
| 1 | += JavaScript Environments |
| 2 | +:database-version: 23.2.0 |
| 3 | +:database-category: javascript |
| 4 | + |
| 5 | +[[feature_summary]] |
| 6 | + |
| 7 | +JavaScript Environments, just like JavaScript modules, are schema objects persisted in the database. They perform a vital function in applications involving multiple JavaScript modules. Unlike `node.js` or `deno` projects JavaScript modules aren't persisted on the file system, they are stored in the database. Developers cannot simply import modules based on their location in the file system, they need to use environments instead. |
| 8 | + |
| 9 | +The following example demonstrates the use of environments. |
| 10 | + |
| 11 | + |
| 12 | +[source,javascript] |
| 13 | +[subs="verbatim"] |
| 14 | +---- |
| 15 | +create or replace MLE module module_one |
| 16 | +language javascript as |
| 17 | +
|
| 18 | +// this function is exported and will be called by |
| 19 | +// module_2's greeting() function |
| 20 | +export function hello(who) { |
| 21 | +
|
| 22 | + return 'hello ' + who; |
| 23 | +} |
| 24 | +/ |
| 25 | +
|
| 26 | +create or replace MLE module module_two |
| 27 | +language javascript as |
| 28 | +
|
| 29 | +// before module_1's hello() function can be imported a |
| 30 | +// so-called import name must be defined by means of creating |
| 31 | +// a JavaScript environment. The module name does not have to |
| 32 | +// match the import name |
| 33 | +import { hello } from 'module1' |
| 34 | +
|
| 35 | +export function greeting() { |
| 36 | +
|
| 37 | + const who = 'JavaScript'; |
| 38 | + return hello(who); |
| 39 | +} |
| 40 | +/ |
| 41 | +
|
| 42 | +// the mapping between import name and module name is defined |
| 43 | +// in an environment |
| 44 | +create or replace mle env example_env |
| 45 | +imports ( |
| 46 | + 'module1' module module_one |
| 47 | +); |
| 48 | +
|
| 49 | +// with the module in place it is possible to invoke module_2's |
| 50 | +// greeting function. Refer to the section about call specifications |
| 51 | +// for more details about invoking JavaScript code in SQL and PL/SQL |
| 52 | +create or replace function f_greeting |
| 53 | +return varchar2 as |
| 54 | +mle module module_two |
| 55 | +env example_env |
| 56 | +signature 'greeting'; |
| 57 | +/ |
| 58 | +
|
| 59 | +select |
| 60 | + f_greeting; |
| 61 | +
|
| 62 | +---- |
| 63 | + |
| 64 | +.Result |
| 65 | +[source] |
| 66 | +[subs="verbatim"] |
| 67 | +---- |
| 68 | +SQL> create or replace MLE module module_one |
| 69 | + 2 language javascript as |
| 70 | + 3 |
| 71 | + 4 // this function is exported and will be called by |
| 72 | + 5 // module_2's greeting() function |
| 73 | + 6 export function hello(who) { |
| 74 | + 7 |
| 75 | + 8 return 'hello ' + who; |
| 76 | + 9 } |
| 77 | + 10 / |
| 78 | +
|
| 79 | +MLE module created. |
| 80 | +
|
| 81 | +SQL> create or replace MLE module module_two |
| 82 | + 2 language javascript as |
| 83 | + 3 |
| 84 | + 4 // before module_1's hello() function can be imported a |
| 85 | + 5 // so-called import name must be defined by means of creating |
| 86 | + 6 // a JavaScript environment. The module name does not have to |
| 87 | + 7 // match the import name |
| 88 | + 8 import { hello } from 'module1' |
| 89 | + 9 |
| 90 | + 10 export function greeting() { |
| 91 | + 11 |
| 92 | + 12 const who = 'JavaScript'; |
| 93 | + 13 return hello(who); |
| 94 | + 14 } |
| 95 | + 15 / |
| 96 | +
|
| 97 | +MLE module created. |
| 98 | +
|
| 99 | +SQL> -- the mapping between import name and module name is defined |
| 100 | +SQL> -- in an environment |
| 101 | +SQL> create or replace mle env example_env |
| 102 | + 2 imports ( |
| 103 | + 3 'module1' module module_one |
| 104 | + 4 ); |
| 105 | +
|
| 106 | +MLE env created. |
| 107 | +
|
| 108 | +SQL> -- with the module in place it is possible to invoke module_2's |
| 109 | +SQL> -- greeting function. Refer to the section about call specifications |
| 110 | +SQL> -- for more details about invoking JavaScript code in SQL and PL/SQL |
| 111 | +SQL> create or replace function f_greeting |
| 112 | + 2 return varchar2 as |
| 113 | + 3 mle module module_two |
| 114 | + 4 env example_env |
| 115 | + 5 signature 'greeting'; |
| 116 | + 6 / |
| 117 | +
|
| 118 | +Function created. |
| 119 | +
|
| 120 | +SQL> -- call the function |
| 121 | +SQL> select |
| 122 | + 2 f_greeting; |
| 123 | +
|
| 124 | +F_GREETING |
| 125 | +------------------------------------------------------------------------------- |
| 126 | +hello JavaScript |
| 127 | +---- |
| 128 | + |
| 129 | +== Benefits |
| 130 | + |
| 131 | +JavaScript Environments play a crucial role during the development of JavaScript stored procedures. They are most useful providing means to map an import name as used in a JavaScript module to the actual module itself. Furthermore they are essential entities for the definition of link:javascript-call-specifications.html[call specifications. ] |
| 132 | + |
| 133 | +== Further information |
| 134 | + |
| 135 | +* Availability: All Offerings |
| 136 | +* https://docs.oracle.com/en/database/oracle/oracle-database/23/mlejs/mle-js-modules-and-environments.html#GUID-EB682328-BA26-4422-9304-62D412D28B2F[Documentation] |
| 137 | +* https://blogs.oracle.com/developers/post/using-javascript-community-modules-in-oracle-database-23c-free-developer-release[Blog post] |
0 commit comments