3.5 Managing MLE Environments

MLE environments are schema objects that can be managed in the database. In the SQL Developer extension for VS Code, you can create, edit and delete MLE environments.

For more information about MLE, see Introduction to Oracle Database Multilingual Engine in the Oracle Database JavaScript Developer's Guide.

The actions available to you are:

3.5.1 Create an MLE Environment

To create an MLE environment:

  1. In the Connections panel, for a specific connection, click the + icon in the MLE Environments node and then click Create.

    The Create pane appears.

  2. In the MLE Environment Name field, enter a name for the environment.

    The SQL pane displays the DDL code for the new MLE environment.

  3. Click Apply.

    An empty MLE environment is created and appears in the Connections panel under MLE Environments.

3.5.1.1 Example for Create an MLE Environment

This example demonstrates the creation of myfactorialenv MLE environment and how to import the factorial_mod JavaScript module into this environment.

  1. In the Connections panel, right-click MLE Environments and then click Create.

    The Create panel appears.

  2. In the MLE Environment Name field, enter a name for the environment, myfactorialenv.

    The SQL pane displays the DDL code for the new MLE environment.

  3. Click Apply.

    An empty myfactorialenv environment is created and appears in the left pane under MLE Environments.

  4. In the Connections panel, expand MLE Environments, right-click myfactorialenv and click Add Imports.

    The Add Imports pane appears.

  5. In Module Name field, select the module (factorial_mod) to import.
  6. In Import Name field, enter a name for your import.

  7. Click Apply.

    To view the imported module, in the Connections panel, right click myfactorialenv and select Open. Three tabs are displayed for the MLE environment: Errors, Grants and SQL.

    The imported module appears in the Imports panel.

3.5.2 Import a Module to an MLE Environment

To import a module for a selected MLE environment:

  1. In the Connections panel, right-click the MLE environment name and select Add Imports.

    The Add Imports panel appears.

  2. In the Module Name field, a list of the modules that you have created or have been granted access to appears in the list. Select a module from the list.
  3. Enter an Import Name for the module.
  4. Click Apply.

3.5.3 Compile an MLE Environment

To compile an MLE environment, in the Connections panel, right-click the selected environment name and select Compile.

To compile all MLE environments for a connection, in the Connections panel, right-click MLE environments and select Compile All.

To compile all invalid MLE environments, in the Connections panel, right-click MLE environments and select Compile All Invalid.

3.5.4 Delete an MLE Environment

To delete an MLE environment:

  1. In the Connections panel, right-click the selected MLE environment and select Drop.

    The Drop panel appears.

  2. Click Apply.

3.5.5 Post Execution Debugging

MLE Post Execution Debugging enables developers to seamlessly troubleshoot and refine their JavaScript code running inside Oracle Database as MLE modules. With this feature, you gain deep insights into your code’s behavior after execution by leveraging familiar debugging workflows.

Post execution debugging allows you to:

  • Set breakpoints within your deployed MLE JavaScript modules.
  • Initiate and control debugging sessions to inspect code flow.
  • Step through code (continue, step in, step out) to analyze logic and execution paths.
  • Examine variable values and call stacks to diagnose and resolve issues efficiently.
  • Stop or restart debugging sessions for iterative development.

Debugging MLE Module

  1. Prepare the MLE function and the invoking script.
    • Ensure your JavaScript function is defined in your MLE module.
    • You need a debug runner file that invokes the function. You can open a new debug runner file containing a sample DBMS_MLE snippet to help invoke the MLE module code for debugging or open an existing debug runner file from your local file system. See About the Debug Runner File.


    Description of mle_java_runnerfile.png follows
    Description of the illustration mle_java_runnerfile.png

  2. Before debugging, set breakpoints in your JavaScript code by clicking in the gutter next to the line numbers.
    Description of add_break_point.png follows
    Description of the illustration add_break_point.png

    Note:

    You must set at least one breakpoint before starting a debug session. Once a debug session is active, you cannot add new breakpoints. To add more, terminate the current debug session, set new breakpoints, then start a new session.
  3. With your debug runner file and breakpoints ready, start the debug session using Start Debugging (Start post-execution debugging) icon in the toolbar.

    Only one debugging session can run at a time.

    The execution will pause at each defined breakpoint. You can inspect variables, view the call stack, and use debug control buttons (continue, step over, step in/out). When all breakpoints are hit or the execution flow ends, the debug session is terminated.

About the Debug Runner File

The debug runner file, typically a SQL worksheet, contains the logic that initiates debugging of the JavaScript code. This file can be associated with any database connection. Make sure all required database objects (such as the MLE module, environment, procedures, and functions) exist in the current connection. If these objects are missing, execution will fail and an error message will be displayed in the Script Output panel (in addition to a warning), because the invoking code is executed in the connection before debugging starts.

Filtering and Breakpoint Management

In the Breakpoints panel, all breakpoints from all open modules are listed. Each breakpoint is associated with a specific database connection, which is shown in the file path or context next to the breakpoint.You can filter the list to show breakpoints only for a selected connection, making it easier to focus on relevant modules during your debug session.

If a breakpoint is linked to a different connection than the one currently being used in your debug session, it is automatically disabled. Disabled breakpoints appear grayed out in the list. When you hover over a disabled breakpoint, a tooltip appears explaining the reason for the breakpoint's status.