I remember Joel Kallman’s talk on the boat at APEX World 2019 in Rotterdam very well. I was sitting in the front row on the right, about two metres away from Joel, enjoying his talk. Because I was that close, I could see the screen of his laptop. He made use of the available technology: presenter view, which allows you to read your prepared text word for word or just ensure that you do not forget to mention an important point. Some people like using presenter view, and others think you should know your slides and therefore just see what the attendees see. I’m in the latter group, also because I was always afraid of mixing up the presenter and audience views and not being able to fix it in time, especially when switching between slides and live demos. So mirroring was and still is easier for me.

The talk was excellent. The content was good. It was well presented. It was his talk. The fact that he used technology to support his presentation does not change that. So at what point does using technology change who we consider the author?

I wonder what Joel would think about AI as we know it today.

How I Looked Things Up in My Early Days

When I was in school, I liked Duden’s Sinn- und sachverwandte Wörter the most. You could look up a word and find synonyms and words with similar meanings. I spent a lot of time looking up words and was constantly irritated by my inability to easily put letters in alphabetical order in my head to decide whether I had to go forwards or backwards. Is “m” before “o”? So I silently say “a, b, c, d, e, f, g, h, i, j, k, l, m, n, o” to the melody of the alphabet song we learned in my first school year (similar to this). And ah, yes, “m” is before “o”. So backwards… Sounds silly, but “a, b, c, d, e, f, g” is probably the phrase I use most in my life.

Back then, I thought it was fancy not to repeat words in the next sentence in my essays, and basically in general, because we were taught that it was a good thing. In the meantime, I have come to believe that you should use the same word to refer to the same thing, regardless of how often it appears in a text. It is less ambiguous. In other words, it is clearer and easier to understand. I believe this is true in IT and in business in general. For poetry, this might be different, but that’s for sure not my domain.

I also used Duden’s Die deutsche Rechtschreibung and the Brockhaus Enzyklopädie to look things up and sometimes stumbled across something interesting while scanning the pages for the original term. Driven by curiosity, I learnt a few things along the way.

In any case, even back then, what I wrote was influenced by things I had read. Sometimes intentionally and, over time, for sure also unintentionally. Learning words and ways of expressing things from others is different from presenting their text or ideas as my own without acknowledgement. That would be plagiarism. But if I could measure how much of my writing was influenced by others, the percentage might well be substantial.

What I want to say is that I started asking for help very early. Often I asked my father, because he basically knew everything and had a perfect memory. It was easier for me to ask him than to look it up myself (remember, I always had to repeat “a, b, c, d” in my head). But more often than not, he just gave me the right book so I could look it up myself and was available to discuss things.

Since then, many technological inventions have improved our ability to look things up ourselves.

My First Contact With AI

I guess my first use of AI tools was DeepL. I didn’t know that at the time, but DeepL has been using neural networks to translate text since its launch in 2017. See How does DeepL work? for an explanation of the technology.

Before DeepL offered DeepL Write, I often translated a text from German to English, then the English result back to German, and that result again to English. I made some adjustments in between and repeated the process until I was satisfied. It usually produced a good result, something I felt I could have written myself if given enough time. I provided the initial input as German text, after all, right?

Autocomplition & Refactoring

Long before today’s AI assistants, IDEs already provided autocompletion and refactoring based on rules. Autocompletion used information about the programming language and the code, and refactoring applied hand-written transformation rules. I used the Loop can be collapsed with Stream API transformation and similar transformations just to better understand newer language alternatives. Some of them I kept, with or without adaptations, and some of them I completely reverted. Once I had reviewed and committed the changes to version control, I considered it my code. I was driving the development, after all, right?

Nowadays, IntelliJ IDEA’s Full Line Code Completion plugin, available as part of the Ultimate subscription, uses a local deep learning model to complete code. So, even if I don’t use an AI assistant to create code, I use local AI to complete code, which I then claim as my own. I was driving the development, after all, right?

Does It Matter?

I guess it depends. On the size of the result, the overall change, the potential impact and so on. When I’m in the driver’s seat, I decide what to accept and take responsibility for the result. However, with large results, I am easily overwhelmed and unable to decide quickly. Being in the driver’s seat is only useful if I can still understand and assess what I’m accepting.

A presenter view, a dictionary and an AI assistant do different things. AI can produce a whole text or a large amount of code. If the AI writes the code, what makes it “my code”? With spec-driven development, I might think of myself as the owner of the guardrails I give the AI: the specifications, including the input for test cases. But that is a topic for another post.

When you ask the CEO of a startup company whether they developed the company’s product alone, they will most probably say no and explain who else was involved in making it happen. It is usually a team effort. Even products from single-person companies often involve help from somebody or something behind the scenes.

AI tools are becoming part of that process. Just tools, but tools that can improve our efficiency. Ignoring them where they are useful may put us at a disadvantage in a functioning market economy. But using them does not automatically make us more efficient. The time needed to check and correct the result also counts.

So for me, the question is how we can use AI tools in a beneficial way and in which contexts that makes sense.

Yes, I Use AI on This Blog

So yes, I use AI on this blog too. You can see this very clearly in the featured images: most of those published since 29 July 2024 were generated by AI. I also use tools such as Grammarly, DeepL and AI assistants to help with the text. For this post, I started with my own draft and used AI to review the language and logic and help write this ending.

The memories, opinions and the reason for writing this post are mine. I decide what to keep, what to change and what to publish. And I remain responsible for the result. For me, that is an important part of being the author, even when I have help.

Looking something up in a book, translating a text and asking AI for a suggestion are different kinds of help. I need to understand what each tool contributes and decide whether it is useful for what I want to say. Sometimes it is. Sometimes I have to change it or start again.

I cannot know what Joel would think about today’s AI. But I remember his talk and what he shared with us. Presenter view was part of how he delivered it, and it was still his talk. That memory is a useful reminder for my own work: I can use the available tools and still put my own thoughts and care into what I share.

And yes, I still consider this my blog post. Without blushing ;-)

The post Some Thoughts About Joel and AI #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.

No, SYSDATE is not deterministic. However, it behaves very similarly to a deterministic function within an Oracle Database SQL statement.

Background

On a customer site, we used faketime on the OS to change the date and time for testing purposes. As long as you only travel forward in time, the Oracle Database behaves fine. The solution worked well for the last 8 years. However, this approach had some drawbacks, such as the need for a full-blown VM (we cannot change the time in an isolated manner within a Docker container), disabling time synchronisation processes and issues with third-party software due to failed sanity/license checks. This approach prevented us from simplifying the architecture of the testing environment.

We were exploring alternatives to travel in time only within the Oracle Database. One option was to set FIXED_DATE, and another to replace calls to SYSDATE, SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP with custom functions that added an offset to the current date/time. For the latter, I’d like to share some simplified test results.

But before that, let’s look at some definitions.

Definitions

Wikipedia defines a deterministic algorithm in computer science as follows:

In computer science, a deterministic algorithm is an algorithm that, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states. Deterministic algorithms are by far the most studied and familiar kind of algorithm, as well as one of the most practical, since they can be run on real machines efficiently.

The Oracle Database PL/SQL Language Reference defines deterministic for the deterministic_clause as follows:

• A function is deterministic if the DETERMINISTIC clause appears in either a declaration or the definition of the function.
• The DETERMINISTIC clause may appear at most once in a function declaration and at most once in a function definition.
• A deterministic function must return the same value on two distinct invocations if the arguments provided to the two invocations are the same.
• A DETERMINISTIC function may not have side effects.
• A DETERMINISTIC function may not raise an unhandled exception.
• If a function with a DETERMINISTIC clause violates any of these semantic rules, the results of its invocation, its value, and the effect on its invoker are all undefined.

How to Check?

There are two ways to check if a function is deterministic. Firstly, you can query the data dictionary like this:

select deterministic 
  from dba_procedures
 where procedure_name = 'SYSDATE';

select deterministic 
  from dba_procedures
 where procedure_name = 'SYSDATE';

DETERMINISTIC
-------------
NO

DETERMINISTIC
-------------
NO

Secondly, you can check the source code to see if it contains a deterministic_clause. SYSDATE is defined in the STANDARD package as a wrapper to the kernel function pessdt and has no deterministic_clause.

create or replace package STANDARD AUTHID CURRENT_USER is …
  function SYSDATE return DATE;
    pragma FIPSFLAG('SYSDATE', 1452); …
end;

create or replace package STANDARD AUTHID CURRENT_USER is …
  function SYSDATE return DATE;
    pragma FIPSFLAG('SYSDATE', 1452); …
end;

create or replace package body STANDARD is …
  -- Bug 1287775: back to calling ICD.
  -- Special: if the ICD raises ICD_UNABLE_TO_COMPUTE, that means we should do
  -- the old 'SELECT SYSDATE FROM DUAL;' thing.  This allows us to do the
  -- SELECT from PL/SQL rather than having to do it from C (within the ICD.)
  function sysdate return date is
    d date;
  begin
    d := pessdt;
    return d;
  exception
    when ICD_UNABLE_TO_COMPUTE then
      select sysdate into d from sys.dual;
      return d;
  end; …
end;

create or replace package body STANDARD is …
  -- Bug 1287775: back to calling ICD.
  -- Special: if the ICD raises ICD_UNABLE_TO_COMPUTE, that means we should do
  -- the old 'SELECT SYSDATE FROM DUAL;' thing.  This allows us to do the
  -- SELECT from PL/SQL rather than having to do it from C (within the ICD.)
  function sysdate return date is
    d date;
  begin
    d := pessdt;
    return d;
  exception
    when ICD_UNABLE_TO_COMPUTE then
      select sysdate into d from sys.dual;
      return d;
  end; …
end;

So, SYSDATE is clearly non-deterministic.

Interesting are the comments regarding bug 1287775 (APPSST:PERF: SERVER SIDE PL/SQL SHOULD NOT USE SQL TO OBTAIN SYSDATE). It does not seem to be entirely about performance. The last update of the bug was in mid-2021. I was unable to find out why a pessdt call may fail, and why getting SYSDATE via a query from dual should solve the problem. Anyway, it’s not essential for this blog post.

Comparing SYSDATE to a Non-Deterministic Function

Let’s create a non-deterministic function APPDATE that returns SYSDATE. Then, we compare the SYSDATE and APPDATE results in a PL/SQL cursor.

create or replace function appdate return date is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

create or replace function appdate return date is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:28:29 2025-10-13 08:28:29
2 2025-10-13 08:28:29 2025-10-13 08:28:30
3 2025-10-13 08:28:29 2025-10-13 08:28:31
4 2025-10-13 08:28:29 2025-10-13 08:28:32
5 2025-10-13 08:28:29 2025-10-13 08:28:33


PL/SQL procedure successfully completed.

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:28:29 2025-10-13 08:28:29
2 2025-10-13 08:28:29 2025-10-13 08:28:30
3 2025-10-13 08:28:29 2025-10-13 08:28:31
4 2025-10-13 08:28:29 2025-10-13 08:28:32
5 2025-10-13 08:28:29 2025-10-13 08:28:33


PL/SQL procedure successfully completed.

You see, the results are different except for the first row. We had to set the fetch array size to one to ensure the sleep call on line 25 affects each fetched record. Otherwise, you would see the effect between the batch of records defined by the default fetch size.

Comparing SYSDATE to a Deterministic Function

Let’s make the APPDATE function deterministic and rerun the script.

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
set arraysize 1
declare
   cursor c is 
        select rownum,
               to_char(sysdate, 'YYYY-MM-DD HH24:MI:SS') as the_sysdate, 
               to_char(appdate, 'YYYY-MM-DD HH24:MI:SS') as the_appdate
          from user_objects
         where rownum <= 5;
   r c%rowtype;     
begin
    open c;
    sys.dbms_output.put_line('# THE_SYSDATE         THE_APPDATE');
    sys.dbms_output.put_line('- ------------------- -------------------');
    loop
        fetch c into r;
        exit when c%notfound;
        sys.dbms_output.put_line(r.rownum || ' ' || r.the_sysdate || ' ' || r.the_appdate);
        sys.dbms_session.sleep(1);
    end loop;
    close c;
end;
/

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:29:00 2025-10-13 08:29:00
2 2025-10-13 08:29:00 2025-10-13 08:29:00
3 2025-10-13 08:29:00 2025-10-13 08:29:00
4 2025-10-13 08:29:00 2025-10-13 08:29:00
5 2025-10-13 08:29:00 2025-10-13 08:29:00


PL/SQL procedure successfully completed.

Function APPDATE compiled

# THE_SYSDATE         THE_APPDATE
- ------------------- -------------------
1 2025-10-13 08:29:00 2025-10-13 08:29:00
2 2025-10-13 08:29:00 2025-10-13 08:29:00
3 2025-10-13 08:29:00 2025-10-13 08:29:00
4 2025-10-13 08:29:00 2025-10-13 08:29:00
5 2025-10-13 08:29:00 2025-10-13 08:29:00


PL/SQL procedure successfully completed.

Now we have the same result. SYSDATE is evaluated once for the whole query as the deterministic function APPDATE. There is obviously some special treatment of SYSDATE in the Oracle Database code for SQL statements. It handles it similarly to a deterministic function or a bind variable. That’s good. This matches the read consistency concepts. We do not want to get different results of SYSDATE in a single query.

But how does it behave in PL/SQL?

SYSDATE in PL/SQL

24 years ago, someone posted a puzzle in the forum of dbasupport.com that covered the same topic. I snitched the code from there and adapted it slightly.

set serveroutput on size unlimited
declare
   i binary_integer := 0;
begin
   while sysdate = sysdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

set serveroutput on size unlimited
declare
   i binary_integer := 0;
begin
   while sysdate = sysdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Left the loop after 2957099 iterations


PL/SQL procedure successfully completed.

Left the loop after 2957099 iterations


PL/SQL procedure successfully completed.

It appears to be an endless loop, but it is not. The two SYSDATE calls are evaluated independently, and eventually they return different results. Of course, the number of iterations varies. Therefore, the algorithm could be used as a kind of random number generator.

APPDATE in PL/SQL

Let’s use the deterministic variant of the APPDATE function in the same script.

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Function APPDATE compiled

declare 
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 5

https://docs.oracle.com/error-help/db/ora-01426/


More Details :
https://docs.oracle.com/error-help/db/ora-01426/
https://docs.oracle.com/error-help/db/ora-06512/

Function APPDATE compiled

declare 
*
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at line 5

https://docs.oracle.com/error-help/db/ora-01426/


More Details :
https://docs.oracle.com/error-help/db/ora-01426/
https://docs.oracle.com/error-help/db/ora-06512/

Luckily, the maximum value of a binary integer is 2,147,483,647. With a NULL statement on line 12, the script would run endlessly. It looks like the APPDATE function is evaluated only once within the WHILE statement.

We told the PL/SQL compiler that the APPDATE function is deterministic. So the same input (none in this case) always produces the same output. This is a lie. However, the compiler is a nice component and trusts us. So it can come up with some optimisations to improve the runtime of our code and produce a solution that calls APPDATE only once. And boom, we have an endless loop.

Let’s verify this.

PLSQL_OPTIMIZE_LEVEL

The PL/SQL compiler knows the following four optimisation levels:

• 0 = Oracle Database 9i style with some minor improvements
• 1 = Various optimisations, does not move code, therefore required when debugging PL/SQL
• 2 = More optimisations, including moving code around, this is the default in 19c/23ai
• 3 = Even more optimisations

The documentation leaves us in the dark about what each level does exactly. However, one thing is sure. The higher the level, the more aggressive the optimisation.

So let’s try the previous code with level 0.

alter session set plsql_optimize_level = 0;
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

alter session set plsql_optimize_level = 0;
create or replace function appdate return date deterministic is
begin
  return sysdate;
end;
/

set serveroutput on size unlimited
declare 
   i binary_integer := 0;
begin
   while appdate = appdate loop
      i := i + 1;
   end loop;
   dbms_output.put_line('Left the loop after ' || i || ' iterations');
end;
/

Session altered.


Function APPDATE compiled

Left the loop after 3224661 iterations


PL/SQL procedure successfully completed.

Session altered.


Function APPDATE compiled

Left the loop after 3224661 iterations


PL/SQL procedure successfully completed.

Ha, this worked. No endless loop. We get a similar result with level 1. However, levels 2 and 3 lead to an endless loop.

This example should illustrate that we should not lie to the compiler. Sooner or later, another optimisation in a newer version could break our code.

Conclusion

In fact, the previous paragraph could be a good conclusion. However, at the beginning of this post, I mentioned a real use case where we were evaluating an alternative to the faketime library. We opted for FIXED_DATE because it is simple to apply and worked for the application under test. The application uses SYSDATE exclusively for business-relevant dates and times. SYSTIMESTAMP, CURRENT_DATE, CURRENT_TIMESTAMP and LOCALTIMESTAMP, which are unaffected by FIXED_DATE, are used only for logging purposes.

The idea of providing a custom function that returns SYSDATE with a centrally defined offset might have worked in our case. But providing a solution that behaves like SYSDATE is much more challenging than I thought. We would need something that is evaluated once in a SQL statement and per call in other cases. Passing SYSDATE as a default parameter to a deterministic function does the trick. Either way, I’m glad we opted for the simpler solution, which meant there was no need to change the code base.

The post Is SYSDATE Deterministic? #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.

This is a translation of my German article “PL/SQL oder JavaScript in der Oracle Datenbank 23ai?” published in the Red Stack Magazine No. 6/2024 on 11 October 2024.

Why Do We Need Code in the Database?

I see the following reasons for this.

1. We bring the code to the data rather than the data to the code. This allows us to process the data efficiently on the database server and deliver the result to the client in just a few network round trips. This uses fewer resources, is more cost-effective and faster than if we had to transport the data to the client and process it there.
2. We take responsibility for the quality of the data stored in the database. Typically, we write data once and read it often. Therefore, we should store data correctly so that consumers can rely on the data when they read it. In this sense, the logic for validating the data belongs in the database. This logic is often more extensive than what today’s database constraints provide. In other words, we need code in the database as part of an API to keep our data consistent and correct.

Even if your database applications do not follow the principles of SmartDB or PinkDB, there are benefits to selectively using code in the database. And if your company policy categorically forbids code in the database, it is probably time to reconsider.

PL/SQL Without SQL

Let’s pretend we need a function to convert a timestamp to Unix time. Wikipedia defines the Unix time as follows.

Unix time is a date and time representation widely used in computing. It measures time by the number of non-leap seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix epoch.

Listing 1 shows how we can implement this in PL/SQL.

create or replace function to_epoch_plsql(
   in_ts in timestamp
) return number is
   co_epoch_date constant timestamp with time zone := 
      timestamp '1970-01-01 00:00:00 UTC';
   l_interval    interval day(9) to second (3);
begin
   l_interval := in_ts - co_epoch_date;
   return 1000 * (extract(second from l_interval)
         + extract(minute from l_interval) * 60
         + extract(hour from l_interval) * 60 * 60
         + extract(day from l_interval) * 60 * 60 * 24);
end;
/

create or replace function to_epoch_plsql(
   in_ts in timestamp
) return number is
   co_epoch_date constant timestamp with time zone := 
      timestamp '1970-01-01 00:00:00 UTC';
   l_interval    interval day(9) to second (3);
begin
   l_interval := in_ts - co_epoch_date;
   return 1000 * (extract(second from l_interval)
         + extract(minute from l_interval) * 60
         + extract(hour from l_interval) * 60 * 60
         + extract(day from l_interval) * 60 * 60 * 24);
end;
/

The to_epoch_plsql function expects a timestamp, a timestamp with timezone would be better. We have omitted this to keep the example as simple as possible. Although the solution may seem simple, we are reimplementing existing functionality. We had to find out how Unix time works, what role time zones play, what leap seconds are for, and that Unix time is used in milliseconds, not seconds.

Wouldn’t it be nice to be able to use an existing, tested function in the database to keep our application’s code to a minimum? Even though there is no to_epoch function in SQL, the Java Development Kit (JDK) offers such functionality. The Oracle Java Virtual Machine (OJVM) is an embedded component of the Oracle Database 23.5. It’s a JDK version 11.

Java Without SQL

The Oracle Database has supported Java stored procedures since version 8i Release 1. This means that we can provide a to_epoch_java function as shown in Listing 2.

create or replace and compile java source named "Util" as
public class Util {
   public static long toEpoch(java.sql.Timestamp ts) {
      return ts.getTime();
   }
}
/
create or replace function to_epoch_java(in_ts in timestamp) 
  return number is language java name 
    'Util.toEpoch(java.sql.Timestamp) return java.lang.long';
/

create or replace and compile java source named "Util" as
public class Util {
   public static long toEpoch(java.sql.Timestamp ts) {
      return ts.getTime();
   }
}
/
create or replace function to_epoch_java(in_ts in timestamp) 
  return number is language java name 
    'Util.toEpoch(java.sql.Timestamp) return java.lang.long';
/

For Java, we need to create a class and a call specification. The purpose of the call specification is, among other things, to map the types of input and output data between SQL and Java. For example, to map the return value of java.lang.long to number.

The code no longer contains the formula for converting a timestamp to Unix time, but it is quite extensive. Is there an easy way in JavaScript?

JavaScript Without SQL

With Oracle Database 23ai, we can create JavaScript modules.

create or replace mle module util_mod language javascript as   
export function toEpoch(ts) {
   return ts.valueOf();
}
/
create or replace function to_epoch_js(in_ts in timestamp) 
   return number is 
      mle module util_mod 
      signature 'toEpoch(Date)';
/

create or replace mle module util_mod language javascript as   
export function toEpoch(ts) {
   return ts.valueOf();
}
/
create or replace function to_epoch_js(in_ts in timestamp) 
   return number is 
      mle module util_mod 
      signature 'toEpoch(Date)';
/

The implementation of to_epoch_js in Listing 3 is similar to to_epoch_java. A module in JavaScript and then an MLE call specification. However, it is no longer necessary to fully map the input data types in JavaScript. The Oracle Database defines default values. These can be overridden, but do not need to be explicitly defined as in Java. It is not possible to map the output data type. In this case, it must be possible to convert the return value to a number, otherwise, a runtime error will occur.

However, the implementation for this simple case is quite extensive. Oracle has probably realised this and provided an alternative.

create or replace function to_epoch_js2("in_ts" in timestamp)
   return number is
      mle language javascript ' return in_ts.valueOf();';
/

create or replace function to_epoch_js2("in_ts" in timestamp)
   return number is
      mle language javascript ' return in_ts.valueOf();';
/

The to_epoch_js2 function in Listing 4 is equivalent to to_epoch_js but significantly simpler than any of the other variants. However, an inline MLE call specification is only applicable to JavaScript code without dependencies on other modules, this means for JavaScript code without an import command.

Performance of to_epoch_...

Anyone who has worked with Java stored procedures in the database knows that the initialisation of the OJVM in a new database session slows down the response time considerably. This is not the case with MLE because it uses a GraalVM native image. Simply put, it reads only the memory contents of a file, similar to waking your laptop from hibernation. This makes it possible to start a Java program within a millisecond. The native image is integrated into the database as a shared library $ORACLE_HOME/lib/libmle.so. This means that the MLE provides JavaScript via Java, but is completely independent of the OJVM.

In Figure 1 we compare the runtimes of 100,000 function calls. Instead of seconds, we use a normalised unit of time, which makes comparing easier and results less dependent on the hardware stack used.

All experiments were performed using the Oracle Database 23.5 Free Edition on an AMD Ryzen R1600 processor-based system. The shortest time of five repetitions was taken into account. You can reproduce these experiments using the scripts in this GitHub repository.

The to_epoch_plsql, to_epoch_java and to_epoch_js variants are called from a PL/SQL loop. This means 100,000 context switches between PL/SQL and Java or JavaScript. The fourth variant, to_epoch_jsloop, calls toEpoch from a JavaScript loop. In this case, the context switching between PL/SQL and JavaScript makes processing about 50 times slower.

Based on these results, we should avoid context switching between PL/SQL and JavaScript if possible. The performance of JavaScript in the database is impressive in this case. Quite different from the OJVM.

Memory Usage of to_epoch_...

Figure 2 shows the maximum memory used at the end of a to_epoch_… function call. The call was made in a new database session and contains the memory requirements of the measuring instruments.

JavaScript uses significantly more memory than PL/SQL. If you take this into account when sizing the database server and connection pools, this should not be a problem nowadays.

Using a 3rd Party JavaScript Library

Let’s say we want to validate email addresses in our database without actually sending a test email. The rules for a valid email address are quite extensive. In the JavaScript ecosystem, we can find open-source libraries for such requirements that can be used in the database without modification. For this example, we use validator.js, which can validate not only email addresses but also credit card numbers, EAN, IBAN and much more. Using SQLcl’s script command, we can load npm modules directly into the database.

script https://raw.githubusercontent.com/PhilippSalvisberg/mle-sqlcl/main/mle.js install validator_mod https://esm.run/validator@13.12.0 13.12.0

select version, language_name, length(module)
  from user_mle_modules
 where module_name = 'VALIDATOR_MOD';

script https://raw.githubusercontent.com/PhilippSalvisberg/mle-sqlcl/main/mle.js install validator_mod https://esm.run/validator@13.12.0 13.12.0

select version, language_name, length(module)
  from user_mle_modules
 where module_name = 'VALIDATOR_MOD';

VERSION    LANGUAGE_NAME       LENGTH(MODULE)
---------- ---------------- ----------------- 
13.12.0    JAVASCRIPT                  123260

VERSION    LANGUAGE_NAME       LENGTH(MODULE)
---------- ---------------- ----------------- 
13.12.0    JAVASCRIPT                  123260

The script mle.js in Listing 5 is not read from the local file system as usual but via a URL from GitHub. The script creates a JavaScript module validator_mod with the contents of the URL https://esm.run/validator@13.12.0, which is a minimised, browser-optimised version of the validator.js module in the npm software registry. The last parameter 13.12.0 is the version of the module stored in the Oracle Data Dictionary.

In Listing 6, we create the MLE call specification in a PL/SQL package. The is_mail function accepts only a string as a parameter. The validator options are defined in the package body. This simplifies uniform use in the database application.

create or replace package validator_api is
   function is_email(
      in_email in varchar2
   ) return boolean deterministic;
end validator_api;
/
create or replace package body validator_api is
   function is_email_internal(
      in_email   in varchar2,
      in_options in json
   ) return boolean deterministic as mle module validator_mod 
   signature 'default.isEmail(string, any)';

   function is_email(
      in_email in varchar2
   ) return boolean deterministic is
   begin
      return is_email_internal(
                in_email   => in_email,
                in_options => json('
                   {
                      "allow_display_name": false,
                      "allow_undescores": false,
                      "require_display_name": false,
                      "allow_utf8_local_part": true,
                      "require_tld": true,
                      "allow_ip_domain": false,
                      "domain_specific_validation": false,
                      "blacklisted_chars": "",
                      "ignore_max_length": false,
                      "host_blacklist": ["dubious.com"],
                      "host_whitelist": []
                   }
                ')
             );
   end is_email;
end validator_api;
/

create or replace package validator_api is
   function is_email(
      in_email in varchar2
   ) return boolean deterministic;
end validator_api;
/
create or replace package body validator_api is
   function is_email_internal(
      in_email   in varchar2,
      in_options in json
   ) return boolean deterministic as mle module validator_mod 
   signature 'default.isEmail(string, any)';

   function is_email(
      in_email in varchar2
   ) return boolean deterministic is
   begin
      return is_email_internal(
                in_email   => in_email,
                in_options => json('
                   {
                      "allow_display_name": false,
                      "allow_undescores": false,
                      "require_display_name": false,
                      "allow_utf8_local_part": true,
                      "require_tld": true,
                      "allow_ip_domain": false,
                      "domain_specific_validation": false,
                      "blacklisted_chars": "",
                      "ignore_max_length": false,
                      "host_blacklist": ["dubious.com"],
                      "host_whitelist": []
                   }
                ')
             );
   end is_email;
end validator_api;
/

Listing 7 shows the use of the validator in SQL. The second email address is invalid because of the allow_display_name option. The third e-mail address is formally correct, but it uses a domain listed under host_blacklist.

select e_mail, validator_api.is_email(e_mail) as is_valid
  from (values
          ('esther.muster@example.com'),
          ('Esther Muster <esther.muster@example.com>'),
          ('esther.muster@dubious.com')
       ) test_data (e_mail);

select e_mail, validator_api.is_email(e_mail) as is_valid
  from (values
          ('esther.muster@example.com'),
          ('Esther Muster <esther.muster@example.com>'),
          ('esther.muster@dubious.com')
       ) test_data (e_mail);

E_MAIL                                      IS_VALID
----------------------------------------- ----------
esther.muster@example.com                          1
Esther Muster <esther.muster@example.com>          0
esther.muster@dubious.com                          0

E_MAIL                                      IS_VALID
----------------------------------------- ----------
esther.muster@example.com                          1
Esther Muster <esther.muster@example.com>          0
esther.muster@dubious.com                          0

JavaScript With SQL

The MLE provides a global variable session of type IConnection to communicate with the current database session. Listing 8 shows an example of a simple update statement using bind variables.

create or replace mle module increase_salary_mod 
language javascript as
export function increase_salary(deptno, by_percent) {
   session.execute(`
      update emp
         set sal = sal + sal * :by_percent / 100
         where deptno = :deptno`, [by_percent, deptno]);
}
/
create or replace procedure increase_salary_js(
   in_deptno     in number,
   in_by_percent in number
) as mle module increase_salary_mod
signature 'increase_salary(number, number)';
/

create or replace mle module increase_salary_mod 
language javascript as
export function increase_salary(deptno, by_percent) {
   session.execute(`
      update emp
         set sal = sal + sal * :by_percent / 100
         where deptno = :deptno`, [by_percent, deptno]);
}
/
create or replace procedure increase_salary_js(
   in_deptno     in number,
   in_by_percent in number
) as mle module increase_salary_mod
signature 'increase_salary(number, number)';
/

PL/SQL With SQL

Listing 9 shows the PL/SQL counterpart to the JavaScript code in Listing 8, using dynamic SQL with bind variables.

create or replace procedure increase_salary_dplsql(
   in_deptno     in number,
   in_by_percent in number
) is
begin
   execute immediate '
      update emp
         set sal = sal + sal * :by_percent / 100
      where deptno = :deptno' using in_by_percent, in_deptno;
end increase_salary_dplsql;
/

create or replace procedure increase_salary_dplsql(
   in_deptno     in number,
   in_by_percent in number
) is
begin
   execute immediate '
      update emp
         set sal = sal + sal * :by_percent / 100
      where deptno = :deptno' using in_by_percent, in_deptno;
end increase_salary_dplsql;
/

Experienced PL/SQL developers would not write it this way, as syntax and semantic errors are only thrown at runtime. In addition, it is more expensive for the Oracle Database to execute dynamic SQL, and the use of database objects is not stored in the Oracle Data Dictionary. Instead, experienced PL/SQL developers use static SQL whenever possible and sensible. The code is shorter and SQL injection is impossible. Listing 10 shows the static SQL variant.

create or replace procedure increase_salary_plsql(
   in_deptno     in number,
   in_by_percent in number
) is
begin
   update emp
      set sal = sal + sal * in_by_percent / 100
    where deptno = in_deptno;
end increase_salary_plsql;
/

create or replace procedure increase_salary_plsql(
   in_deptno     in number,
   in_by_percent in number
) is
begin
   update emp
      set sal = sal + sal * in_by_percent / 100
    where deptno = in_deptno;
end increase_salary_plsql;
/

Performance of increase_salary_...

Figure 3 compares the runtimes of 100,000 procedure calls in a PL/SQL loop. Only increase_salary_jsloop uses a JavaScript loop. This avoids 100,000 context switches between PL/SQL and JavaScript. In other words, the difference between increase_salary_js and increase_salary_jsloop is the cost of 100,000 context switches.

In the Oracle Database version 23.5, JavaScript is about 5 to 6 times slower than PL/SQL in this example when we use dynamic SQL. In the Oracle Database version 23.3, the difference was a factor of 7, which makes me optimistic that we can expect further performance improvements in future versions.

Based on these experiments, it is difficult to make general statements about the performance differences between PL/SQL and JavaScript. However, it appears that PL/SQL code with SQL statements has an advantage over JavaScript.

MLE Environment

Accessing the network using the JavaScript Fetch API is possible, If the appropriate permissions have been granted using the PL/SQL package dbms_network_acl_admin. However, for security reasons, JavaScript cannot access the database server’s file system.

JavaScript runtime environments such as Node.js, Deno, Bun or web browsers, access the file system to import other JavaScript modules. For that, you need an MLE environment in the Oracle Database. Listing 11 shows how to create and use it.

create or replace mle env demo_env
    imports(
        'increase_salary' module increase_salary_mod,
        'validator'       module validator_mod,
        'util'            module util_mod
    )
    language options  'js.strict=true, js.console=false,
                       js.polyglot-builtin=true'
;
create or replace mle module increase_salary_loop_mod 
language javascript as   
import {increase_salary} from "increase_salary";
export function increase_salary_loop(deptno,by_percent,times){
   for (let i=0; i<times; i++) {
      increase_salary(deptno, by_percent);
   }
}
/
create or replace procedure increase_salary_jsloop(
   in_deptno     in number,
   in_by_percent in number,
   in_times      in number
) as mle module increase_salary_loop_mod
env demo_env
signature 'increase_salary_loop(number, number, number)';
/

create or replace mle env demo_env
    imports(
        'increase_salary' module increase_salary_mod,
        'validator'       module validator_mod,
        'util'            module util_mod
    )
    language options  'js.strict=true, js.console=false,
                       js.polyglot-builtin=true'
;
create or replace mle module increase_salary_loop_mod 
language javascript as   
import {increase_salary} from "increase_salary";
export function increase_salary_loop(deptno,by_percent,times){
   for (let i=0; i<times; i++) {
      increase_salary(deptno, by_percent);
   }
}
/
create or replace procedure increase_salary_jsloop(
   in_deptno     in number,
   in_by_percent in number,
   in_times      in number
) as mle module increase_salary_loop_mod
env demo_env
signature 'increase_salary_loop(number, number, number)';
/

The MLE environment demo_env maps the import name increase_salary to the MLE module increase_salary_mod. This import is used in the MLE module increase_salary_loop_mod. However, the MLE environment is not assigned there. This is only done in the MLE call specification increase_salary_jsloop.

MLE environments allow JavaScript code to be structured in the same way inside and outside the database. In most cases, a single MLE environment will be sufficient for an application. Multiple MLE environments are required if different language options are used per module, or if different versions of a module are to be loaded with the same import name.

Is Tom Kyte’s Mantra Still Valid?

One of the things Tom Kyte is famous for is his mantra. There are several variations, but all have the same message. This variant is from Expert Oracle Database Architecture, Third Edition, 2014. On page 3 he writes:

I have a pretty simple mantra when it comes to developing database software, one that has been consistent for many years:

• You should do it in a single SQL statement if at all possible. And believe it or not, it is almost always possible. This statement is even truer as time goes on. SQL is an extremely powerful language.
• If you can’t do it in a single SQL Statement, do it in PL/SQL—as little PL/SQL as possible! Follow the saying that goes “more code = more bugs, less code = less bugs.”
• If you can’t do it in PL/SQL, try a Java stored procedure. The times this is necessary are extremely rare nowadays with Oracle9i and above. PL/SQL is an extremely competent, fully featured 3GL.
• If you can’t do it in Java, do it in a C external procedure. This is most frequently the approach when raw speed or using a third-party API written in C is needed.
• If you can’t do it in a C external routine, you might want to seriously think about why it is you need to do it.

With Oracle Database 23ai, I would put JavaScript on the same level as PL/SQL. Before Java, definitely. Furthermore, it is not just a question of whether something can be done in SQL or PL/SQL. If we need a functionality that already exists in the JavaScript ecosystem, we should consider using it rather than reimplementing it in SQL or PL/SQL just because it’s possible. Ultimately, it is also about the maintainability of the application and the technical debt we are incurring.

Conclusion

MLE was introduced as an experimental feature at Oracle Open World 2017. Since then, MLE and the underlying GraalVM technology have been continuously improved and have reached a good, production-ready state in Oracle Database 23ai. It is ideally suited for integrating existing, tested functionality from the JavaScript ecosystem into the Oracle Database.

We still need to figure out how to develop, test, debug and deploy JavaScript with SQL. In any case, JavaScript is a real alternative to PL/SQL, even if PL/SQL scores with static SQL and better performance.

The post PL/SQL vs. JavaScript in the Oracle Database 23ai #JoelKallmanDay appeared first on Philipp Salvisberg's Blog.