Who Changed My Code? No More Code Conflicts in Shared Oracle DB DEV Environments [Loki]

Ever worked in an Oracle Database with a bunch of other developers?

You know that annoying moment when you tweak package XYZ on Tuesday, but suddenly your changes are gone because someone else jumped in and messed with it on Wednesday? Yeah, we’ve all been there.

You may have been using GIT (and you should) or some CI/CD tools, such as SQLcl and Liquibase. However, it would be nice NOT to have our changes overwritten.

People will often say:

Just communicate!

Set private environments (Docker, Podman, etc.) for each developer

But let’s be real—that’s sometimes tough to manage.

Imagine if you could easily lock the object you’re working on, and anyone trying to change it would get a heads-up.

Pretty cool, right?

That’s what Loki does!

Super simple example to get your attention.

User JOHN creates a new function on the schema HR:

What happened in the background? Besides creating a function, the Loki feature created a lock on this object.

After a while, user RAFAL tries to overwrite the function that JOHN created.

This won’t happen, and RAFAL is informed that this function is locked by JOHN.

Now, it’s time to communicate :)

Did I get your attention?

If yes, read further.

What is Loki?

Loki is a utility app [author’s note: written in APEX] that can help prevent developers from “stepping on each other’s toes” while working together in a shared development database. Loki creates “locks” on objects that are associated with a developer, ensuring only that developer can make changes to the object until the lock is released. [source]

The Oracle team created Loki, and it is available in their GitHub repo here

What does development with Loki look like?

As I showed in my example, the Loki feature created a lock on the object that user JOHN created.

This lock can be seen in the Loki APEX application:

Imagine that user JOHN is working on some other objects:

Loki automatically created a lock on the newly created table and package specification

Until the locks on those objects are released, other users won’t be able to modify those objects.

Now, the working flow could be:

1. RAFAL communicates with JOHN and asks if he can modify his locked objects

2. JOHN says “yes!” and has four options:

   • Unlock each object one by one:

     

   • Unlock all of his (JOHN’s) locks:

     

   • Transfer all of his (JOHN’s) locks directly to RAFAL

   • Transfer some of his (JOHN’s) locks directly to RAFAL

After the locks are released or transferred, RAFAL can start working on those objects.

Once work is completed, locks on changed / new objects should be released.

3. There can always be another way when JOHN says “$%^&” meaning “no, you can’t”. But sooner or later, he will say yes :) In the meantime, Rafal will work on objects that are free to take.

What objects can be locked by Loki?

At the moment of writing this, according to Oracle’s Loki repository, supported objects are:

• COMMENT

• CONSTRAINT

• FUNCTION

• INDEX

• MATERIALIZED_VIEW

• MATERIALIZED_VIEW_LOG

• PACKAGE

• PROCEDURE

• REF_CONSTRAINT

• SEQUENCE

• SYNONYM

• TABLE

• TRIGGER

• TYPE

• VIEW

Extra features of Loki

1. Loki tracks the exact DDL that caused locking of an object.

2. You can use Loki to create a lock on an object that doesn’t exist yet.

3. You can also create a lock on an object that you are about to change in the future (but it has not been changed yet)

   

4. The Loki APEX app offers an Administrator role for privileged users, allowing them to manage all user locks.

Summary

I hope you like this not-yet-promoted and probably not-known feature.

I heard rumours that Loki is about to be somehow integrated with GIT and SQLcl Projects in the future - but don’t ask me, I don’t know any more :)

Coming soon

In the next blog post about Loki, I will demonstrate how to install and configure it in your Oracle Database.

Stay tuned.