ANTLR Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/antlr/ Database-centric development Wed, 01 Jul 2026 22:57:34 +0000 en-US hourly 1 https://wordpress.org/?v=7.0 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png ANTLR Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/antlr/ 32 32 Detecting Security Vulnerabilities With the APEXlang Parser https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/ https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/#respond Mon, 29 Jun 2026 12:12:21 +0000 https://www.salvis.com/blog/?p=19914 Introduction A parser for the APEXlang grammar enables the development of tools beyond the scope of the APEXlang compiler included in SQLcl, SQL Developer for VS Code, and ORDS. These tools can perform static code analysis, convert code, generate documentation, and visualise different aspects of an APEX application. A linter, for example, […]

The post Detecting Security Vulnerabilities With the APEXlang Parser appeared first on Philipp Salvisberg's Blog.

]]> Introduction

A parser for the APEXlang grammar enables the development of tools beyond the scope of the APEXlang compiler included in SQLcl, SQL Developer for VS Code, and ORDS. These tools can perform static code analysis, convert code, generate documentation, and visualise different aspects of an APEX application.

A linter, for example, can check whether an APEXlang file conforms to defined quality standards. These standards may cover project- or company-specific conventions as well as more general concerns, such as detecting potential security vulnerabilities.

In this blog post, I explain the elements of an APEXlang file that are the basis of Grisselbav’s APEXlang parser. Then I demonstrate how to use the parser in a simple Java program to detect a security vulnerability.

Elements of an APEXlang File

An APEXlang file consists of three basic building blocks: components, properties, and groups. These elements can also be nested, as shown later.

Here’s an excerpt of Oracle’s Universal Theme demo application.apx file:

1) Excerpt of UT’s application.apx
app UT (
    name: Universal Theme 26.1 Reference
    version: 26.1.0
    group: @universal-theme
    logo {
        type: text
        text: Universal Theme
    }
    // ...removed code...
)
Component

There is one component in this example. It starts on line 1 and ends on line 10. app is the type of the component and UT the component name.

A component body starts with a left parenthesis ( and ends with a right parenthesis ).

Property

In this example, we have 5 properties. The property keys are name, version, group, type and text. The value of a property follows a colon :. For name The value is Universal Theme 26.1 Reference, for version the value is 26.1.0 and so on.

Please note that a property starts on a new line, and the property value starts after the colon and ends on a new line. This way, no delimiter characters are required for most property values. However, if leading or trailing spaces are significant, you have to pass the property value as a single-line string, which is enclosed in double quotes.

Group (of properties)

The properties type and text are part of a group named logo. The group in this example covers lines 5 to 8.

A group body starts with an open curly bracket { and ends with a close curly bracket }.

Properties which are not part of a group are called direct properties. This means they are defined directly in a component. Examples of direct properties are name, version and group.

Nested Elements

We have seen that a component may contain properties and groups. But it is also possible to nest elements.

  • Components may contain other components besides properties and groups
  • Property values may contain groups besides simple values

There is no limit to the number of levels for nested elements.

Here’s an example:

2) Nested Component and Group
app UT (
    // ...removed code...
    pwaShortcut getting-started (
        name: Getting Started
        sequence: 10
        shortcut {
            target: {
                page: 500
            }
            description: Getting Started Page - Initial Page
        }
        comments {
            comments: -
        }
    )
   // ...removed code...
)

A nested component starts on line 3 and a nested group on line 7.

APEXlang Grammar

apxFile rule of APEXlang grammar

While the grammar documented in apexlang. ebnf of the API Reference defines both the language structure and the valid APEXlang elements, the grammar used by Grisselbav’s APEXlang parser is limited to structural concerns.

Because the parser focuses solely on syntax rather than semantic validation, the grammar remains remarkably compact.

Click on the image above to view all the syntax diagrams. Alternatively, view the ANTLR4 source files, ApexLangLexer.g4 and ApexLangParser.g4, which were used to generate the parser available on Maven Central.

APEX-SERT

APEX-SERT is an APEX application that scans a selected APEX application for security vulnerabilities. A vulnerability is detected by querying APEX dictionary views. All rules are defined in the APEX-SERT Rules.json file.

To demonstrate a practical use case, let’s look at the security check “Embed in Frames” implemented by APEX-SERT.

When the property “Embed in Frames” is set to Allow, the application may be vulnerable to “clickjacking” attacks as explained in the help text of the page designer. See screenshot below.

I changed the original value from Allow from same origin to Allow to simulate a security vulnerability.

APEX-SERT runs a query similar to the following to find violations of this rule:

3) Find Violations with SQL
select application_id, application_name, browser_frame 
  from apex_applications
 where browser_frame not in ('Deny', 'Allow from same origin');
APPLICATION_ID APPLICATION_NAME               BROWSER_FRAME
-------------- ------------------------------ -------------
        101252 Universal Theme 26.1 Reference Allow

So, the value of Embed in Frames is provided in the browser_frame column of the APEX dictionary view apex_applications.

But where can we find this information in the APEXlang files?

Link Page Designer Property to APEXlang

We find the “Embed in Frames” property in the page designer by navigating to “Shared Components” -> “Application Definition” -> “Security” -> “Browser Security”.

According to the apexlang. ebnf there is a security group within the app component. Here’s the relevant excerpt:

3) Property embedInFrames within apexlang.ebnf
<app-security> ::= <indent> "security" <ws> "{" <line-end> { <app-security-property-line> } <indent> "}" <line-end>
<app-security-property-line> ::= <indent> <app-security-property> <line-end>
<app-security-property> ::= "deepLinking" ":" <ws> ( "true" | "false" ) (* required; type: SELECT LIST *)
  | "enableDictation" ":" <ws> <boolean> (* required; type: YES NO *)
  | "browserCache" ":" <ws> ( "true" | "false" ) (* required; type: SELECT LIST *)
  | "embedInFrames" ":" <ws> ( "deny" | "allowSameOrigin" | "allow" ) (* required; type: SELECT LIST *)
  | "referrerPolicy" ":" <ws> ( "noReferrer" | "noReferrerWhenDowngrade" | "origin" | "originWhenCrossOrigin" | "sameOrigin" | "strictOrigin" | "strictOriginWhenCrossOrigin" | "unsafeUrl" ) (* required; type: SELECT LIST *)
  | "htmlEscapingMode" ":" <ws> ( "basic" | "extended" ) (* required; type: SELECT LIST *)
  | "httpResponseHeaders" ":" <ws> <multiline-string> (* type: TEXT EDITOR *)
  | "runtimeApiUsage" ":" <ws> <array-of-string-like-value> (* type: CHECKBOXES *)

We find on line 352 the definition of the property embedInFrames with a list of valid values. In this case, the property key is unique. This means that no other component or group uses the property key embedInFrames. Therefore, we can search the folder containing the .apx files for the string embedInFrames: to find the position of this property.

The matching property is located in the application.apx file.

Here’s an excerpt.

4) Property embedInFrames in application.apx
    authorization {
        runOnPublicPages: true
    }
    security {
        deepLinking: true
        embedInFrames: allow
        runtimeApiUsage: modifyThisApp
    }
    sessionStateProtection {
        allowUrlsCreatedAfter: 1999-08-04T00:00:00
        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
    }

Please note that properties with default values are skipped when an APEX application is exported. Therefore, we would not see the embedInFrames property if its value were Deny.

Find Vulnerability With APEXlang Parser

We now have all the information we need. We can write a small demo program. This program will find this vulnerability in an APEXlang file.

The parser exposes the parse tree through ANTLR4-generated context classes. Each parser rule becomes a context class. For example, the class ApexLangParser.PropertyContext represents the property parser rule. This makes it easy to traverse the ApexLangDocument using Java streams.

5) DemoFindVulnerability.java
//DEPS com.grisselbav:apexlang-parser:0.2.0

import com.grisselbav.apexlang.grammar.*;

class DemoFindVulnerability {
    public static void main(String[] args) {
        var apxSource = """
                app UT (
                    name: Universal Theme 26.1 Reference
                    version: 26.1.0
                    // ... removed code ...
                    authorization {
                        runOnPublicPages: true
                    }
                    security {
                        deepLinking: true
                        embedInFrames: allow
                        runtimeApiUsage: modifyThisApp
                    }
                    sessionStateProtection {
                        allowUrlsCreatedAfter: 1999-08-04T00:00:00
                        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
                    }
                    // ... removed code ...
                )
                """;
        var doc = ApexLangDocument.parse(apxSource);
        var violations = doc.getAllContentsOfType(ApexLangParser.PropertyContext.class)
                .stream()
                .filter(p -> p.name.getText().equals("embedInFrames")
                        && p.value().getText().equals("allow"))
                .toList();
        for (var violation : violations) {
            System.err.println("Found vulnerability: " + violation.getText());
        }
    }
}

This program embeds the APEXlang source code to scan in the apxSource variable. To run the program, save it as DemoFindVulnerability.java, then run it with JBang. This will automatically resolve the Maven dependency on the first line.

jbang DemoFindVulnerability.java
[jbang] Resolving dependencies...
[jbang]    com.grisselbav:apexlang-parser:0.2.0
[jbang] Dependencies resolved
[jbang] Building jar for DemoFindVulnerability.java...
Found vulnerability: 
        embedInFrames: allow

Are Regular Expressions An Alternative?

In this case, we could have used a regular expression to identify the violation.

However, as soon as the rules become more complicated, e.g. if we want to ensure that the property is part of the security group and the security group is part of the app component, regular expressions are no longer suited. But a parser is. Because we can navigate the parse tree and adjust the filter settings as follows.

6) DemoFindVulnerability2.java with extended filter
//DEPS com.grisselbav:apexlang-parser:0.2.0

import com.grisselbav.apexlang.grammar.*;

class DemoFindVulnerability2 {
    public static void main(String[] args) {
        var apxSource = """
                app UT (
                    name: Universal Theme 26.1 Reference
                    version: 26.1.0
                    // ... removed code ...
                    authorization {
                        runOnPublicPages: true
                    }
                    security {
                        deepLinking: true
                        embedInFrames: allow
                        runtimeApiUsage: modifyThisApp
                    }
                    sessionStateProtection {
                        allowUrlsCreatedAfter: 1999-08-04T00:00:00
                        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
                    }
                    // ... removed code ...
                )
                """;
        var doc = ApexLangDocument.parse(apxSource);
        var violations = doc.getAllContentsOfType(ApexLangParser.PropertyContext.class)
                .stream()
                .filter(p -> p.name.getText().equals("embedInFrames")
                        && p.value().getText().equals("allow")
                        && p.parent.parent instanceof ApexLangParser.GroupContext g
                        && g.name.getText().equals("security")
                        && g.parent.parent.parent instanceof ApexLangParser.ComponentContext c
                        && c.type.getText().equals("app"))
                .toList();
        for (var violation : violations) {
            System.err.println("Found vulnerability: " + violation.getText());
        }
    }
}

Integration Into dbLinter

The APEX-SERT “Embed in Frames” rule has been added to the dbLinter repository as rule A-1010: Never allow application pages within an HTML frame. The VS Code extension, the CLI and the SonarQube plugin now support checks implemented for APEXlang.

Here’s a short silent video that demonstrates how this security vulnerability is detected and quickly fixed.

Conclusion

The APEXlang grammar is intentionally simple through focusing on structural elements, leaving semantic validation, such as valid property values, to the APEXlang compiler in SQLcl, SQL Developer and VS Code.

Integrating the APEXlang parser into dbLinter was straightforward, as was implementing the first APEXlang-based dbLinter rule.

The next step is to identify which additional rules would be beneficial to bring to dbLinter. If you have any suggestions, please let me know. Even better, open a GitHub issue in the dbLinter GitHub repository.

Thank you.

The post Detecting Security Vulnerabilities With the APEXlang Parser appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/feed/ 0 IslandSQL Final Episode 10: Parsing PL/pgSQL https://www.salvis.com/blog/2024/07/29/islandsql-final-episode-10-parsing-pl-pgsql/ Mon, 29 Jul 2024 14:00:55 +0000 https://www.salvis.com/blog/?p=13526 Introduction IslandSQL is a parser for SQL files targeting OracleDB or PostgreSQL. The parser is available on Maven Central and can process SQL*Plus, SQLcl or psql statements besides SQL statements. However, the focus is on statements with static DML statements and code in PL/SQL and PL/pgSQL. For static code analysis, for example. […]

The post IslandSQL Final Episode 10: Parsing PL/pgSQL appeared first on Philipp Salvisberg's Blog.

]]> Introduction

IslandSQL is a parser for SQL files targeting OracleDB or PostgreSQL. The parser is available on Maven Central and can process SQL*Plus, SQLcl or psql statements besides SQL statements. However, the focus is on statements with static DML statements and code in PL/SQL and PL/pgSQL. For static code analysis, for example.

In PostgreSQL create function, create procedure and do accept code as a string. This simplifies parsing and the implementation of additional languages. As a result, you can write functions and procedures in SQL, PL/pgSQL, PL/Tcl, PL/Perl and PL/Python in any standard PostgreSQL distribution.

Starting with IslandSQL version 0.10 it’s possible to parse SQL and PL/pgSQL in strings and extend the parse tree accordingly. In this blog post, I will explain how this works.

This VS Code extension uses IslandSQL in a language server to report syntax errors and to produce parse trees as shown in this blog post.

PL/pgSQL as String

Let’s look at a do statement executing a PL/pgSQL block provided as a string.

1) hello_world.sql
do '
begin
   raise notice $$Hello World!$$;
end
';
NOTICE:  Hello World!
DO

The parse tree in IslandSQL version 0.9 looks as follows:

Parse tree with PL/pgSQL as string

Look at the parse tree. It is quite simple. Interesting is the PL/pgSQL block. The content in single quotes is represented as a single token. The big rectangle at the bottom. It’s a single token regardless of the code size.

PL/pgSQL as Subtree

Parsing PL/pgSQL as a string is easy. The lexer produces the token for the string containing the PL/pgSQL code. The parser does not need to understand the PL/pgSQL at all.

But this does not help analyse the PL/pgSQL code. We need a parser that

  • understands PL/pgSQL
  • parses PL/pgSQL code provided as a string
  • extends the main parse tree by sub-parse trees with PL/pgSQL code

The IslandSQL parser in version 0.10 does exactly that. It produces this parse tree by default:

Parse tree with PL/pgSQL as string and as subtree

The PL/pgSQL code is represented twice in this parse tree. Once as a single token. And once as a node named postgresqlPlpgsqlCode.

PL/pgSQL as Subtree Only

Maybe you do not like it when PL/pgSQL code is represented twice in the parse tree. In this case, you can override the default options when creating an IslandSQL document.

The IslandSQL library requires Java 8 or newer. In the next example, we use Java 22 to reduce boilerplate code. Implicitly declared classes are still in preview. Hence we have to pass the parameters --enable-preview --source 22 when running the HelloWorld.java program.

Explaining HelloWorld.java

In line 13 we create the IslandSQL document with a series of parameters. One of them is removeCode(true) in line 19 which oversteers the default behaviour and removes the code as a string from the parse tree.

In line 21 we print a profile. Thanks to Cary Millsap, I can’t deal with performance issues without thinking about a bicycle, a Ferrari and kissing… The profile helps to understand where the parser has spent its time.

Finally, in lines 22 and 23 we print the parse tree. Once as a simple textual hierarchy and once as a DOT graph. You can visualise the result in Edotor.net, for example.

2) HelloWorld.java
import ch.islandsql.grammar.IslandSqlDialect;
import ch.islandsql.grammar.IslandSqlDocument;
import ch.islandsql.grammar.util.ParseTreeUtil;

void main() {
    var source = """
            do '
            begin
               raise notice $$Hello World!$$;
            end
            ';
            """;
    var doc = new IslandSqlDocument.Builder()
            .sql(source)
            .hideOutOfScopeTokens(false)
            .dialect(IslandSqlDialect.POSTGRESQL)
            .profile(true)
            .subtrees(true)
            .removeCode(true)
            .build();
    System.out.println(doc.getParserMetrics().printProfile());
    System.out.println(ParseTreeUtil.printParseTree(doc.getFile()));
    System.out.println(ParseTreeUtil.dotParseTree(doc.getFile()));
}
java --enable-preview --source 22 -cp .:islandsql-0.10.0.jar:antlr4-runtime-4.13.1.jar HelloWorld.java
Profile
=======

Total memory used by parser    : 5’164 KB
Total time spent in parser     : 27.918 ms
Total time recorded by profiler: 14.167 ms (100%)

Rule Name (Decision)                          Time (ms) Percent Invocations Lookahead Max Lookahead Ambiguities Errors
---------------------------------------- -------------- ------- ----------- --------- ------------- ----------- ------
string (1887)                                    10.302   72.72           2         0             0           0      0
plsqlStatement (1129)                             1.337    9.44           1         0             0           0      0
postgresqlDo (576)                                0.750    5.30           1         0             0           0      0
postgresqlPlpgsqlCode (6)                         0.735    5.19           2         0             0           0      0
statement (11)                                    0.566    3.99           1         0             0           0      0
sqlEnd (1888)                                     0.314    2.21           1         0             0           0      0
postgresqlRaiseStatement (1260)                   0.134    0.95           1         0             0           0      0
postgresqlRaiseStatement (1269)                   0.030    0.21           1         0             0           0      0

file
  statement
    doStatement
      postgresqlDo
        K_DO:do
        postgresqlPlpgsqlCode
          K_BEGIN:begin
          plsqlStatement
            postgresqlRaiseStatement
              K_RAISE:raise
              raiseLevel
                K_NOTICE:notice
              string:dollarString
                DOLLAR_STRING:$$Hello World!$$
              SEMI:;
          K_END:end
      sqlEnd
        SEMI:;
  <EOF>

digraph islandSQL {
  bgcolor="transparent"
  "1155757579" [shape=ellipse label="file" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "1155757579" -> "1785111044"
  "1155757579" -> "1482748887"
  "1785111044" [shape=ellipse label="statement" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "1785111044" -> "494894055"
  "494894055" [shape=ellipse label="doStatement" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "494894055" -> "1123226989"
  "494894055" -> "500885941"
  "1123226989" [shape=ellipse label="postgresqlDo" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "1123226989" -> "1115381650"
  "1123226989" -> "616412281"
  "1115381650" [shape=box label="do" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "616412281" [shape=ellipse label="postgresqlPlpgsqlCode" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "616412281" -> "2118096382"
  "616412281" -> "878861517"
  "616412281" -> "746394140"
  "2118096382" [shape=box label="begin" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "878861517" [shape=ellipse label="plsqlStatement" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "878861517" -> "1705665942"
  "1705665942" [shape=ellipse label="postgresqlRaiseStatement" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "1705665942" -> "1731763384"
  "1705665942" -> "1100619942"
  "1705665942" -> "87242619"
  "1705665942" -> "864248990"
  "1731763384" [shape=box label="raise" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "1100619942" [shape=ellipse label="raiseLevel" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "1100619942" -> "285074186"
  "285074186" [shape=box label="notice" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "87242619" [shape=ellipse label="dollarString" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "87242619" -> "15892131"
  "15892131" [shape=box label="$$Hello World!$$" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "864248990" [shape=box label=";" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "746394140" [shape=box label="end" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "500885941" [shape=ellipse label="sqlEnd" style=filled fillcolor="#bfe6ff" fontname="Helvetica"]
  "500885941" -> "484841769"
  "484841769" [shape=box label=";" style=filled fillcolor="#fadabd" fontname="Helvetica"]
  "1482748887" [shape=box label="<EOF>" style=filled fillcolor="#fadabd" fontname="Helvetica"]
}

The parse tree looks now like this:

Parse tree with PL/pgSQL as subtree only

SQL Dialect

In line 16 of the previous HelloWorld.java program we set the dialect to POSTGRESQL. Is that required? – No, it’s not. But when do we need to set the SQL dialect in IslandSQL? – When the lexical incompatibility between OracleDB and PostgreSQL leads to syntax errors in the code to be parsed.

What? – Let me explain.

Identifiers

OracleDB and PostgreSQL use different characters to build an identifier. The following table shows the differences. The allowed characters are listed in square brackets. Read \p{Alpha} as any alphabetic letter in the character set of the database.

DBMSAllowed as First CharacterAllowed in Subsequent Characters
OracleDB[\p{Alpha}][_$#0-9\p{Alpha}]
PostgreSQL[_\p{Alpha}][_$0-9\p{Alpha}]

PostgreSQL allows identifiers that start with an underscore. That’s not a problem. However, OracleDB allows the hash sign (#) to be used in an identifier. That leads to unexpected results when the PostgreSQL code uses the bitwise XOR operator without spaces around it. Here’s an example

3) One or two identifiers in select_list?
select a#b from t;

PostgreSQL expects that the columns a and b exists in table t.

OracleDB expects that the column a#b exists in table t.

In this case, IslandSQL can parse the code without errors. However, the parse tree might not look as expected. That’s a documented limitation and cannot be influenced by setting the dialect. At least not in version 0.10 of IslandSQL. Nevertheless, it shows the impact of a lexical incompatibility.

Inquiry Directives

PL/SQL supports predefined and custom Inquiry Directives. These directives are lexically incompatible with PostgreSQL dollar-quoted string constants.

Here’s an example:

4) Using custom inquiry directives
alter session set plsql_ccflags = 'custom1:41, custom2:42';
begin
   dbms_output.put_line($$custom1);
   dbms_output.put_line($$custom2 || '(2)');
end;

By default, this causes a parse error, because $$custom1);\n dbms_output.put_line($$ is identified as a dollar-quoted string constant by the lexer. As a result, the code is interpreted like this:

5) Visualising how two custom inquiry directives are treated as a string
alter session set plsql_ccflags = 'custom1:41, custom2:42';
begin
   dbms_output.put_line('custom1);
   dbms_output.put_line('custom2 || '(2)');
end;

This makes it clearer, why we get a syntax error in line 4 at custom2.

In this case, we have to set the SQL dialect to ORACLEDB to parse custom_inquiry_directives.sql without errors.

Predefined Inquiry Directives

To simplify the use, we want to avoid specifying the SQL dialect. One way to achieve that is to handle predefined inquiry directives in the GENERIC SQL dialect.

Here’s an example, that does not report syntax errors:

6) Using predefined inquiry directives
begin
   dbms_output.put_line($$plsql_line);
   dbms_output.put_line($$plsql_line || '(2)');
end;

We know the predefined inquiry directives and can deal with them in the lexer.

However, this special treatment can cause problems in corner cases like this one:

7) Using the name of a predefined inquiry directive at the start of a dollar-quoted string constant
do '
begin
   raise notice $$plsql_line is a predefined inquiry directive$$;
end
';

In such cases, we should use the POSTGRESQL dialect to avoid parse errors.

Detect SQL Dialect

Is there a way to detect the SQL dialect of an SQL input automatically? Sure. Several. I’m sure there is a way to use an LLM to get a reasonable result. I’m more of a rule-based guy. So we could parse the code with one dialect and on parse errors try other dialects. If all dialects produce errors, we could choose the one with the fewest errors.

This sounds costly, right? Therefore I decided to start with a simple SQL dialect detection mechanism. The current implementation looks like this:

8) Excerpt of IslandSqlDocument.java in version 0.10.0
private static IslandSqlDialect guessDialect(String sql) {
    return sql.contains("\n/\n") ? IslandSqlDialect.ORACLEDB : IslandSqlDialect.GENERIC;
}

In other words, if the code contains a slash followed by a newline character in the first column of a line, then we go with the ORACLEDB dialect. In all other cases, we go with the GENERIC SQL dialect.

My first version was even simpler. However, I had to add a final \n to the search string to ensure that SQL code containing multiline comments is not recognized as ORACLEDB dialect. Files with Windows newline characters are always recognized as GENERIC. That’s the price when trying to keep things simple and fast.

Now, the ORACLEDB SQL dialect is correctly detected in the next example. As a result, no syntax errors are reported.

9) Using custom inquiry directives in a PL/SQL Block ending on slash
alter session set plsql_ccflags = 'custom1:41, custom2:42';
begin
   dbms_output.put_line($$custom1);
   dbms_output.put_line($$custom2 || '(2)');
end;
/

The SQL dialect detection mechanism kicks in when no SQL dialect is specified (null).

Conclusion

Developing a single grammar for OracleDB and PostgreSQL was an interesting work. I learned a lot about the underlying DBMS. I often looked at the grammar documentation and did not understand it fully. So I had to run the provided examples or create some myself. The typical test cases are based on working examples, extended by tests based on the cartesian product of a subset of clauses that verified if I had defined the order, the optionality, and the cardinality according to the documentation.

A challenge is the undocumented stuff. There are various reasons why something is not documented. In the end, it does not matter why something is missing. The parser fails when processing code that works but should not according to the docs. This cannot be covered by tests based on the official documentation. I found some bugs while processing real-life code. And I expect to find more.

This is the season finale of IslandSQL. There won’t be a second season. However, there might be some spin-offs since I plan to build products based on IslandSQL. Therefore I plan to keep the parser compatible with the latest versions of OracleDB and PostgreSQL.

Feedback is welcome. Please leave your comments on this blog post or open an issue in the IslandSQL GitHub repository for questions, bugs or feature requests.

Thank you.

The post IslandSQL Final Episode 10: Parsing PL/pgSQL appeared first on Philipp Salvisberg's Blog.

]]> IslandSQL Episode 9: GraphQL, JSON and Flexible Schemas With Duality Views https://www.salvis.com/blog/2024/06/27/islandsql-episode-9-graphql-json-and-flexible-schemas-with-duality-views/ Thu, 27 Jun 2024 11:31:12 +0000 https://www.salvis.com/blog/?p=13430 Introduction In the last episode, we looked at some new features in Oracle Database 23.4. The IslandSQL grammar now covers all statements that can contain static DML statements and code in PL/SQL and PL/pgSQL. While implementing the ANTLR grammar for the create JSON relational duality view statement I stumbled over GraphQL in […]

The post IslandSQL Episode 9: GraphQL, JSON and Flexible Schemas With Duality Views appeared first on Philipp Salvisberg's Blog.

]]> Introduction

In the last episode, we looked at some new features in Oracle Database 23.4. The IslandSQL grammar now covers all statements that can contain static DML statements and code in PL/SQL and PL/pgSQL.

While implementing the ANTLR grammar for the create JSON relational duality view statement I stumbled over GraphQL in this syntax diagram:

create_json_relational_duality_view railroad diagram

You can use GraphQL as an alternative to a subquery to describe the source of your JSON relational duality view. This feature was already part of 23.3. Usually, I don’t like it when there are several ways to do the same thing. However, in this case, GraphQL helped me to understand the variant of the select statement in the duality view better. GraphQL might even be better suited to describe the content of a duality view.

The funny thing is that JSON is about schema flexibility and GraphQL needs a schema to work. That sounds contradictory. However, if we reduce the scope of schema flexibility to a JSON object within existing entities, this can work quite well.

In this blog post, I explore some features related to the schema flexibility of JSON relational duality views.

  1. Setup
  2. Read-only View à la 19c
  3. Read-only Duality View
  4. Updateable Duality View Using SELECT
  5. Updateable Duality View Using GraphQL
  6. GraphQL vs. SELECT
  7. Insert Into Duality View
  8. Update Duality View
  9. Delete From Duality View

1. Setup

The examples in this blog post require an Oracle Database 23.4 (yes, 23.3 is not enough). In a schema of your choice you can run the following setup script:

1) Setup for extended dept and emp table
set linesize 200
set pagesize 1000  
set long 32767
column ext format a72
column data format a130
alter session set nls_date_format = 'YYYY-MM-DD';

drop table if exists emp;
drop table if exists dept;

create table dept (
   deptno number(2, 0)      not null constraint dept_pk primary key,
   dname  varchar2(14 char) not null,
   loc    varchar2(13 char) not null,
   ext    json(object)
);

create table emp (
   empno    number(4, 0)      not null  constraint emp_pk primary key,
   ename    varchar2(10 char) not null,
   job      varchar2(9 char)  not null,
   mgr      number(4, 0)                constraint emp_mgr_fk references emp,
   hiredate date              not null,
   sal      number(7, 2)      not null,
   comm     number(7, 2),
   deptno   number(2, 0)      not null  constraint emp_deptno_fk references dept,
   ext      json(object)
);

insert into dept (deptno, dname, loc)
values (10, 'ACCOUNTING', 'NEW YORK'),
       (20, 'RESEARCH',   'DALLAS'),
       (30, 'SALES',      'CHICAGO'),
       (40, 'OPERATIONS', 'BOSTON');
commit;
       
insert into emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
values (7566, 'JONES',  'MANAGER',   7839, date '1981-04-02', 2975, null, 20),
       (7698, 'BLAKE',  'MANAGER',   7839, date '1981-05-01', 2850, null, 30),
       (7782, 'CLARK',  'MANAGER',   7839, date '1981-06-09', 2450, null, 10),
       (7788, 'SCOTT',  'ANALYST',   7566, date '1987-04-19', 3000, null, 20),
       (7902, 'FORD',   'ANALYST',   7566, date '1981-12-03', 3000, null, 20),
       (7499, 'ALLEN',  'SALESMAN',  7698, date '1981-02-20', 1600,  300, 30),
       (7521, 'WARD',   'SALESMAN',  7698, date '1981-02-22', 1250,  500, 30),
       (7654, 'MARTIN', 'SALESMAN',  7698, date '1981-09-28', 1250, 1400, 30),
       (7844, 'TURNER', 'SALESMAN',  7698, date '1981-09-08', 1500,    0, 30),
       (7900, 'JAMES',  'CLERK',     7698, date '1981-12-03',  950, null, 30),
       (7934, 'MILLER', 'CLERK',     7782, date '1982-01-23', 1300, null, 10),
       (7369, 'SMITH',  'CLERK',     7902, date '1980-12-17',  800, null, 20),
       (7839, 'KING',   'PRESIDENT', null, date '1981-11-17', 5000, null, 10),
       (7876, 'ADAMS',  'CLERK',     7788, date '1987-05-23', 1100, null, 20);
commit;

Session altered.


Table EMP dropped.


Table DEPT dropped.


Table DEPT created.


Table EMP created.


4 rows inserted.


Commit complete.


14 rows inserted.


Commit complete.

There are a few changes to the well-known dept and emp tables I’d like to highlight:

  • Firstly, primary keys and foreign keys. They are required for the duality views, however, they do not need to be enabled.
  • Secondly, both tables got an additional ext column. The data type is json(object). Before 23.4 there was just a generic json data type. With 23.4 it’s possible to add modifiers. The modifier object is required for flex columns in duality views.

2. Read-Only View à la 19c

Let’s step back and create a view that returns a single JSON column, as in Oracle Database 19c (to make it work in 19c you have to use for example ext clob check (ext is json) instead of ext json(object) in the tables dept and emp).

2) Read-only view à la 19c
create or replace view dept_v as
select json_object(
          deptno,
          dname,
          loc,
          ext,
          'sal': (select sum(sal) from emp where emp.deptno = dept.deptno)
          absent on null
       ) as data
  from dept;

select * from dept_v;
View DEPT_V created.


DATA
--------------------------------------------------------------
{"deptno":10,"dname":"ACCOUNTING","loc":"NEW YORK","sal":8750}
{"deptno":20,"dname":"RESEARCH","loc":"DALLAS","sal":10875}
{"deptno":30,"dname":"SALES","loc":"CHICAGO","sal":9400}
{"deptno":40,"dname":"OPERATIONS","loc":"BOSTON"}

3. Read-Only Duality View

And now let’s try to use the previous subquery in a duality view.

3a) Read-only duality view (ORA-40616)
create or replace json duality view dept_dv as
select json_object(
          deptno,
          dname,
          loc,
          ext,
          'sal': (select sum(sal) from emp where emp.deptno = dept.deptno)
          absent on null
       ) as data
  from dept;
ORA-40616: Cannot create JSON Relational Duality View 'DEPT_DV': using ABSENT ON NULL in JSON_OBJECT() is not permitted.

This does not work. The absent on null clause on line 8 is not supported in a duality view. Let’s remove this line and try again.

3b) Read-only duality view (ORA-40895)
create or replace json duality view dept_dv as
select json_object(
          deptno,
          dname,
          loc,
          ext,
          'sal': (select sum(sal) from emp where emp.deptno = dept.deptno)
       ) as data
  from dept;
ORA-40895: invalid SQL expression in JSON relational duality view (operators except JSON_OBJECT or JSON_ARRAYAGG not allowed)

This still does not work. It’s not allowed to include an aggregate as in line 7. Let’s also remove this line and try again.

3c) Read-only duality view (ORA-40941)
create or replace json duality view dept_dv as
select json_object(
          deptno,
          dname,
          loc,
          ext
       ) as data
  from dept;
ORA-40941: cannot specify a column name or subquery alias for JSON relational duality view

Argh. We cannot use the column alias data on line 7. Let’s remove the alias and try again.

3d) Read-only duality view (ORA-42647)
create or replace json duality view dept_dv as
select json_object(
          deptno,
          dname,
          loc,
          ext
       )
  from dept;
ORA-42647: Missing '_id' field at the root level for JSON-relational duality view 'DEPT_DV'.

Okay, an _id field is required to identify a document. Composite keys can be passed as a JSON array. In this case, we do not need that. We can use deptno. Let’s amend the query and try again.

3e) Read-only duality view
create or replace json duality view dept_dv as
select json_object(
          '_id': deptno,
          dname,
          loc,
          ext
       )
  from dept;

select * from dept_dv;
Json DUALITY created.


DATA
----------------------------------------------------------------------------------------------------------------------------------
{"_id":10,"dname":"ACCOUNTING","loc":"NEW YORK","_metadata":{"etag":"38CBB37294BEE09C6D9867B5B1871FE2","asof":"000025652FBC556F"}}
{"_id":20,"dname":"RESEARCH","loc":"DALLAS","_metadata":{"etag":"1D1973E9B068183129F7DA59F6A9C283","asof":"000025652FBC556F"}}
{"_id":30,"dname":"SALES","loc":"CHICAGO","_metadata":{"etag":"11CC2AE352D52FFDAE0B7A3DFC99F836","asof":"000025652FBC556F"}}
{"_id":40,"dname":"OPERATIONS","loc":"BOSTON","_metadata":{"etag":"B33BBA9A74C046813C59BA0763AD81C9","asof":"000025652FBC556F"}}

Finally, we have a working read-only duality view.

Please note that each document contains a _metadata object. The etag field is a hash value based on all document fields by default. It can be used for optimistic locking. The asof field represents the SCN (system change number). It’s useful for read consistency, this means querying related data in subsequent queries using the flashback_query_clause.

4. Updateable Duality View Using SELECT

Let’s create an updateable duality view that represents all data in our model and uses all relationships.

The highlighted lines contain clauses that work only in a duality view. In other words, the “select” part does not work as a standalone statement as in common relational views.

4) Updateable duality view using select
create or replace json duality view dept_dv as
select json {
          '_id': deptno,
          dname,
          loc,
          ext as flex,
          'emps':
             (
                select json_arrayagg(
                          JSON {
                             emp.empno,
                             emp.ename,
                             emp.job,
                             unnest
                                (
                                   select json {
                                             'mgr'    : mgr.empno with nocheck,
                                             'mgrname': mgr.ename with nocheck
                                          }
                                     from emp mgr
                                    where mgr.empno = emp.mgr
                                ),
                             emp.hiredate,
                             emp.sal,
                             emp.comm,
                             ext as flex
                          }
                       )
                  from emp with insert update delete
                 where emp.deptno = dept.deptno
             )
       }
  from dept with insert update delete;

select json_serialize(data returning clob pretty) as data
  from dept_dv dv
 where dv.data."_id".numberOnly() in (20, 40);
Json DUALITY created.


DATA
------------------------------------------------
{
  "_id" : 20,
  "_metadata" :
  {
    "etag" : "88A4A9648C2CA1752E477545DCA85FD3",
    "asof" : "00002565300350E5"
  },
  "dname" : "RESEARCH",
  "loc" : "DALLAS",
  "emps" :
  [
    {
      "empno" : 7369,
      "ename" : "SMITH",
      "job" : "CLERK",
      "mgr" : 7902,
      "mgrname" : "FORD",
      "hiredate" : "1980-12-17T00:00:00",
      "sal" : 800,
      "comm" : null
    },
    {
      "empno" : 7566,
      "ename" : "JONES",
      "job" : "MANAGER",
      "mgr" : 7839,
      "mgrname" : "KING",
      "hiredate" : "1981-04-02T00:00:00",
      "sal" : 2975,
      "comm" : null
    },
    {
      "empno" : 7788,
      "ename" : "SCOTT",
      "job" : "ANALYST",
      "mgr" : 7566,
      "mgrname" : "JONES",
      "hiredate" : "1987-04-19T00:00:00",
      "sal" : 3000,
      "comm" : null
    },
    {
      "empno" : 7876,
      "ename" : "ADAMS",
      "job" : "CLERK",
      "mgr" : 7788,
      "mgrname" : "SCOTT",
      "hiredate" : "1987-05-23T00:00:00",
      "sal" : 1100,
      "comm" : null
    },
    {
      "empno" : 7902,
      "ename" : "FORD",
      "job" : "ANALYST",
      "mgr" : 7566,
      "mgrname" : "JONES",
      "hiredate" : "1981-12-03T00:00:00",
      "sal" : 3000,
      "comm" : null
    }
  ]
}

{
  "_id" : 40,
  "_metadata" :
  {
    "etag" : "28E9C49240CD26A29FDED7B253A38ED7",
    "asof" : "00002565300350E5"
  },
  "dname" : "OPERATIONS",
  "loc" : "BOSTON",
  "emps" :
  [
  ]
}

Since the ext column in the dept and emp table is empty for all rows, we do not see any additional fields in the two JSON documents.

Due to the unest clause in line 14, the fields mgr and mgrname appear on the same level as all other fields of the table emp.

5. Updateable Duality View Using GraphQL

The next duality view is equivalent to the one in the previous chapter.

The highlighted lines with annotations match the highlighted clauses in the previous statement.

GraphQL requires a model for a query. The Oracle implementation uses tables, primary, and foreign keys to build the underlying model.

Some explanations
  • In line 2, we use the dept table as root. For select, insert, update and delete. This means we get a JSON document per department.
  • In line 8, we use the emp table for the field emps. We expect an array of objects. However, we do not have to tell that explicitly. The Oracle Database will figure that out. There is just one relationship between dept and emp. Therefore it is clear how to join the tables and access the data. For select, insert, update and delete.
  • In line 13, we use the emp table for the fields mgr and mgrname. The access is possible via the foreign keys emp_mgr_fk and emp_deptno_fk. We know that it is emp_mgr_fk but the Oracle Database does not. We have to tell it. We do that with the @link(from: [mgr]) annotation, to use the mgr field for the recursive join. An update of mgrname is not allowed (it is read-only by default). An update of mgr is allowed (it will update the foreign key column in emp).
5) Updateable duality view using GraphQL
create or replace json duality view dept_dv as
dept @insert @update @delete
{
   _id: deptno
   dname
   loc
   ext @flex
   emps: emp @insert @update @delete
      {
         empno
         ename
         job
         emp @unnest @link(from: [mgr])
            {
               mgr    : empno @nocheck
               mgrname: ename @nocheck
            }
         hiredate
         sal
         comm
         ext @flex
      }
};

select json_serialize(data returning clob pretty) as data
  from dept_dv dv
 where dv.data."_id".numberOnly() in (20, 40);
Json DUALITY created.


DATA
------------------------------------------------
{
  "_id" : 20,
  "_metadata" :
  {
    "etag" : "88A4A9648C2CA1752E477545DCA85FD3",
    "asof" : "00002565301D6D5C"
  },
  "dname" : "RESEARCH",
  "loc" : "DALLAS",
  "emps" :
  [
    {
      "empno" : 7369,
      "ename" : "SMITH",
      "job" : "CLERK",
      "mgr" : 7902,
      "mgrname" : "FORD",
      "hiredate" : "1980-12-17T00:00:00",
      "sal" : 800,
      "comm" : null
    },
    {
      "empno" : 7566,
      "ename" : "JONES",
      "job" : "MANAGER",
      "mgr" : 7839,
      "mgrname" : "KING",
      "hiredate" : "1981-04-02T00:00:00",
      "sal" : 2975,
      "comm" : null
    },
    {
      "empno" : 7788,
      "ename" : "SCOTT",
      "job" : "ANALYST",
      "mgr" : 7566,
      "mgrname" : "JONES",
      "hiredate" : "1987-04-19T00:00:00",
      "sal" : 3000,
      "comm" : null
    },
    {
      "empno" : 7876,
      "ename" : "ADAMS",
      "job" : "CLERK",
      "mgr" : 7788,
      "mgrname" : "SCOTT",
      "hiredate" : "1987-05-23T00:00:00",
      "sal" : 1100,
      "comm" : null
    },
    {
      "empno" : 7902,
      "ename" : "FORD",
      "job" : "ANALYST",
      "mgr" : 7566,
      "mgrname" : "JONES",
      "hiredate" : "1981-12-03T00:00:00",
      "sal" : 3000,
      "comm" : null
    }
  ]
}

{
  "_id" : 40,
  "_metadata" :
  {
    "etag" : "28E9C49240CD26A29FDED7B253A38ED7",
    "asof" : "00002565301D6D5C"
  },
  "dname" : "OPERATIONS",
  "loc" : "BOSTON",
  "emps" :
  [
  ]
}

The result is the same as for the variant based on select. The only difference is the asof fields, which is expected.

6. GraphQL vs. SELECT

What I like about the GraphQL variant is that the syntax is simple. It looks similar to the result document and is easy to read. No compromises due to feature parity. I run less risk of trying SQL expressions that are not applicable in a duality view. The downside is that the definition might become ambiguous when extending the model with additional foreign key relationships. You might need to add @link annotations to your existing duality views to successfully recreate them. The variant using select cannot become ambiguous. There is no default join logic in SQL yet.

However, writing complex duality views might be easier with the variant using select. I can temporarily comment out all duality-view-specific clauses to make the select part work as a standalone statement until I’m happy with the result.

From a performance point of view, it should theoretically not matter which syntax variant you use. Any duality view can be built on GraphQL or select. The optimizer has all the information it needs to produce an optimal execution plan for both variants. I see no reason why the internal representation should differ.

Maybe a future version of the Oracle Database will offer options to generate the preferred syntax variant independently of the originally deployed variant. By extending dbms_metadata.get_ddl, for example.

7. Insert Into Duality View

Here’s an example of inserting a JSON document with one department and two employees into the previously created duality view.

Some explanations
  • In line 6, we populate a department field named secret with the boolean value true. This field does not exist in the model. Therefore it will be stored in the ext column of the dept table.
  • In line 13, we set the mgr field to 1. That’s the foreign key column in the emp table.
  • In line 16 we populate an employee field named tools with an array. The field does not exist in the model. Therefore it will be stored in the ext column of the emp table.
7) Insert into duality view (extending the schema)
insert into dept_dv values ('
{
  "_id" : 50,
  "dname" : "MI6",
  "loc" : "LONDON",
  "secret" : true,
  "emps" :
  [
    {
      "empno" : 7,
      "ename" : "BOND",
      "job" : "AGENT",
      "mgr" : 1,
      "hiredate" : "1950-01-01T00:00:00",
      "sal" : 500,
      "tools" : ["Knife", "Garrote Watch", "Walther PPK"]
    },
    {
      "empno" : 1,
      "ename" : "M",
      "job" : "MANAGER",
      "hiredate" : "1940-01-01T00:00:00",
      "sal" : 1000,
      "comm" : 8000
    }
  ]
}
');
commit;

select * from dept where deptno = 50;
select * from emp where deptno = 50;
select json_serialize(data returning clob pretty) as data 
  from dept_dv dv
 where dv.data.secret.booleanOnly();
1 row inserted.


Commit complete.


    DEPTNO DNAME          LOC           EXT
---------- -------------- ------------- --------------------
        50 MI6            LONDON        {"secret":true}


     EMPNO ENAME      JOB              MGR HIREDATE          SAL       COMM     DEPTNO EXT
---------- ---------- --------- ---------- ---------- ---------- ---------- ---------- ---------------------------------------------------
         1 M          MANAGER              1940-01-01       1000       8000         50
         7 BOND       AGENT              1 1950-01-01        500                    50 {"tools":["Knife","Garrote Watch","Walther PPK"]}


DATA
------------------------------------------------
{
  "_id" : 50,
  "_metadata" :
  {
    "etag" : "486256AA33D638F4D339FFE534EC910F",
    "asof" : "0000256530950ADB"
  },
  "dname" : "MI6",
  "loc" : "LONDON",
  "emps" :
  [
    {
      "empno" : 1,
      "ename" : "M",
      "job" : "MANAGER",
      "hiredate" : "1940-01-01T00:00:00",
      "sal" : 1000,
      "comm" : 8000
    },
    {
      "empno" : 7,
      "ename" : "BOND",
      "job" : "AGENT",
      "mgr" : 1,
      "mgrname" : "M",
      "hiredate" : "1950-01-01T00:00:00",
      "sal" : 500,
      "comm" : null,
      "tools" :
      [
        "Knife",
        "Garrote Watch",
        "Walther PPK"
      ]
    }
  ],
  "secret" : true
}

One insert statement leads to three new rows in two tables. Before 23ai, a view and an instead-of trigger would have been required for this.

The fields secret and tools are automatically stored in the flex columns ext. This shows how easy it is to extend the data model on the fly with an insert statement. Without DDL statements. Without PL/SQL code.

8. Update Duality View

Let’s update the previously created document.

Some explanations
  • In line 4, we add a new field named street for the department 50.
  • In line 6, we change the salary for all employees in the department 50 by the factor of 42.
  • In line 9, we increase the salary of BOND by 1. Please note that this is the second change of the salary for this employee in this update statement.
  • In line 10, we append the Aston Martin DB5 to the list of BOND‘s tools.
8) Update duality view (extending the schema again)
update dept_dv v
   set v.data = json_transform(
                   v.data, 
                   set '$.street' = '85 Albert Embankment',
                   nested '$.emps[*]' (
                      set '@.sal' = path '@.sal * 42'
                   ),
                   nested '$.emps[*]?(@.ename == "BOND")' (
                      set '@.sal' = path '@.sal + 1',
                      append '@.tools' = 'Aston Martin DB5'
                   )
                )
 where v.data."_id".numberOnly() = 50;
commit;

select * from dept where deptno = 50;
select * from emp where deptno = 50;
select json_serialize(data returning clob pretty) as data 
  from dept_dv v
 where v.data."_id".numberOnly() = 50;
1 row updated.


Commit complete.


    DEPTNO DNAME          LOC           EXT
---------- -------------- ------------- -----------------------------------------------
        50 MI6            LONDON        {"secret":true,"street":"85 Albert Embankment"}


     EMPNO ENAME      JOB              MGR HIREDATE          SAL       COMM     DEPTNO EXT
---------- ---------- --------- ---------- ---------- ---------- ---------- ---------- ----------------------------------------------------------------------
         1 M          MANAGER              1940-01-01      42000       8000         50
         7 BOND       AGENT              1 1950-01-01      21001                    50 {"tools":["Knife","Garrote Watch","Walther PPK","Aston Martin DB5"]}


DATA
------------------------------------------------
{
  "_id" : 50,
  "_metadata" :
  {
    "etag" : "1591A6C3A20C4BC85C0498F7B1F4031F",
    "asof" : "000025653374F0C7"
  },
  "dname" : "MI6",
  "loc" : "LONDON",
  "emps" :
  [
    {
      "empno" : 1,
      "ename" : "M",
      "job" : "MANAGER",
      "hiredate" : "1940-01-01T00:00:00",
      "sal" : 42000,
      "comm" : 8000
    },
    {
      "empno" : 7,
      "ename" : "BOND",
      "job" : "AGENT",
      "mgr" : 1,
      "mgrname" : "M",
      "hiredate" : "1950-01-01T00:00:00",
      "sal" : 21001,
      "comm" : null,
      "tools" :
      [
        "Knife",
        "Garrote Watch",
        "Walther PPK",
        "Aston Martin DB5"
      ]
    }
  ],
  "secret" : true,
  "street" : "85 Albert Embankment"
}

9. Delete From Duality View

And now, let’s delete department 50 with all its employees to restore the original content of the dept and emp tables.

9) Delete from duality view
delete dept_dv v
 where v.data."_id".numberOnly() = 50;
commit;

select * from dept order by deptno;
select * from emp order by deptno, empno;
1 row deleted.


Commit complete.


    DEPTNO DNAME          LOC           EXT
---------- -------------- ------------- --------------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON


     EMPNO ENAME      JOB              MGR HIREDATE          SAL       COMM     DEPTNO EXT
---------- ---------- --------- ---------- ---------- ---------- ---------- ---------- --------------------
      7782 CLARK      MANAGER         7839 1981-06-09       2450                    10
      7839 KING       PRESIDENT            1981-11-17       5000                    10
      7934 MILLER     CLERK           7782 1982-01-23       1300                    10
      7369 SMITH      CLERK           7902 1980-12-17        800                    20
      7566 JONES      MANAGER         7839 1981-04-02       2975                    20
      7788 SCOTT      ANALYST         7566 1987-04-19       3000                    20
      7876 ADAMS      CLERK           7788 1987-05-23       1100                    20
      7902 FORD       ANALYST         7566 1981-12-03       3000                    20
      7499 ALLEN      SALESMAN        7698 1981-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 1981-02-22       1250        500         30
      7654 MARTIN     SALESMAN        7698 1981-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 1981-05-01       2850                    30
      7844 TURNER     SALESMAN        7698 1981-09-08       1500          0         30
      7900 JAMES      CLERK           7698 1981-12-03        950                    30

14 rows selected.

Outlook

One thing is missing in version 0.9 of IslandSQL grammar. The support of PL/pgSQL in PostgreSQL statements create function, create procedure, create trigger and do. These statements can already be parsed but the PL/pgSQL code passed as string is not further analyzed. This will change in the next and final episode of this season.

The post IslandSQL Episode 9: GraphQL, JSON and Flexible Schemas With Duality Views appeared first on Philipp Salvisberg's Blog.

]]>