SQLcl Projects - Using Liquibase properties to modify your APEX installation

UpdatedMarch 7, 2025

Comments (1)

Galaxy Ethical Tech is a company that specializes in ethical hacking and cybersecurity services, including the recovery of lost or stolen cryptocurrencies like Bitcoin. If you've lost access to your Bitcoin due to hacking, phishing, or other issues, here's how Galaxy Ethical Tech might assist you: They will assess your situation to understand how your Bitcoin was lost (e.g., hacked wallet, phishing scam, lost private keys, etc.) You’ll need to provide details such as transaction IDs, wallet addresses, and any relevant information about the incident.Their team of ethical hackers will use advanced digital forensics tools to trace the movement of your Bitcoin.They analyze blockchain transactions to identify where the funds were transferred and attempt to locate the perpetrator. If your Bitcoin was lost due to forgotten passwords, corrupted wallets, or lost private keys, they may use specialized software to recover access to your wallet.This process often involves brute-force techniques or other recovery methods to regain access.If your Bitcoin was stolen through a phishing scam or fraudulent scheme, they will investigate the scammer’s digital footprint.They may work with law enforcement agencies to track down the culprits and recover your funds. Galaxy Ethical Tech uses blockchain analysis tools to trace the flow of Bitcoin through the blockchain.They identify patterns and connections that could lead to the recovery of your funds.If necessary, they collaborate with legal authorities and law enforcement agencies to take legal action against the perpetrators. This can include freezing accounts or seizing assets linked to the theft. After recovery, they may provide guidance on securing your cryptocurrency assets to prevent future losses.This includes setting up multi-factor authentication, using hardware wallets, and educating you on avoiding phishing scams. No Guarantees : Recovering lost Bitcoin is not always possible, especially if the funds have been moved through multiple wallets or mixed with other cryptocurrencies.Ethical hacking and recovery services can be expensive, so ensure you understand the fees involved before proceeding. Always verify the credibility of the company you’re working with to avoid falling victim to another scam. If you’re considering using Galaxy Ethical Tech or a similar service, ensure they have a proven track record and positive reviews from previous clients. contact them via Email: galaxyethicaltech@mail.com Whatsapp: +15072712442 Telegram: Galaxy_ethical_tech

More from this blog

SQLcl Projects - Dynamic Property File Location Definition

Building on the previous topic of leveraging Liquibase properties to modify APEX installations, we will delve into a companion technique. This one enables users to define as many property files as they wish in the artifact to set it when deploying. T...

Jun 4, 20253 min read643

SQLcl Projects - Dynamic Property File Location Definition

SQLcl: Export and Import data with newlines

Situation Recently I was given a seed data file that was generated from SQLcl with a bunch of INSERT statements, and it worked fine in SQL Developer when ran but would fail in SQLcl with the following: SQL> @DEMO_DATA_TABLE.sql Error starting at lin...

Jan 23, 20246 min read416

SQLcl: Export and Import data with newlines

APEX spinner download indicator using Vanilla JavaScript (async/await)

There are plenty of good resources explaining how to create custom download links in APEX so I will skip over that part and list a couple here: - https://oracle-base.com/articles/misc/apex-tips-file-download-from-a-button-or-link - https://joelkallma...

Mar 8, 20233 min read269

APEX spinner download indicator using Vanilla JavaScript (async/await)

Quick Tip: json_mergepatch

Quick Tip for handling the merging of JSON in Oracle Database!

Oct 12, 20213 min read425

Oracle & More

10 posts

Prereqs

Latest SQLcl
Existing SQLcl Project with an APEX app

Note

On average, I prefer to keep the same Schema name, APEX Application ID, Workspace Name, and Workspace ID across environments and have separate databases. I understand that this isn't the case for everyone, and even with separate instances, you may still have valid reasons to change the Workspace name, Application ID, etc.

Dynamic APEX Install Demo

If you have been using SQLcl Projects, you might have noticed some interesting things in your APEX application's autogenerated changeset file: dist/releases/apex/f<xxx>/f<xxx>.xml. Below is an example of my APEX application export (f100.sql) and staged changes for my SQLcl Project.

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:n0="http://www.oracle.com/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
        http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.3.xsd">
<changeSet id="INSTALL_100" author="SQLCL-Generated"  failOnError="true" runAlways="true">
    <n0:runApexScript objectName="install" objectType="SCRIPT" ownerName="ADMIN" sourceType="STRING"  relativeToChangelogFile="true" >
        <n0:source><![CDATA[
 declare 
 -- sqlcl version      = 24.4.1.0 
 -- override_schema    = ${apex.100.schema}
 -- override_alias     = ${apex.100.alias}
 -- override_workspace = ${apex.100.workspace}
 -- override_app_id    = ${apex.100.appId}

 l_app_id varchar2(255) := q'[100]';  
 l_workspace varchar2(255) := q'[DEMO]'; 

 l_override_workspace varchar2(255) := q'[${apex.100.workspace}]'; 
 l_override_schema varchar2(255) := q'[${apex.100.schema}]'; 
 l_override_alias varchar2(255) := q'[${apex.100.alias}]'; 
 l_override_app_id varchar2(255) := q'[${apex.100.appId}]'; 
 l_generate_offset boolean := false;

 function get_prop_default(p_prop_name varchar2)
 return varchar2 is
 begin  
   return '${apex.100.' || p_prop_name || '}';
 end;  

 begin  
  apex_application_install.clear_all(); 

  -- set workspace 
     if (l_override_workspace != l_workspace and l_override_workspace != get_prop_default('workspace')) then
      apex_application_install.set_workspace(l_override_workspace);
  else 
      apex_application_install.set_workspace(l_workspace);         
  end if; 
  commit;  

  -- set app id 
  if (l_override_app_id != l_app_id and l_override_app_id != get_prop_default('appId')) then
     apex_application_install.set_application_id(l_override_app_id);
    l_generate_offset := true;
  else  
      apex_application_install.set_application_id(l_app_id);
  end if; 

 if (l_override_schema != get_prop_default('schema')) then
    apex_application_install.set_schema(l_override_schema);
  end if;

  -- set alias 
  if (l_override_alias != get_prop_default('alias')) then
    apex_application_install.set_application_alias(l_override_alias);
   l_generate_offset := true;
 end if;

  -- generate offset if necessary
 if (l_generate_offset)  then
    apex_application_install.generate_offset();
 end if;
end;  
/
-- sqlcl_checksum  1740173850613
@f100.sql
        ]]></n0:source>
    </n0:runApexScript>
</changeSet>
</databaseChangeLog>

You can now set the following properties without having to hand write custom code:

override_schema = ${apex.<app_id>.schema}
override_alias = ${apex.<app_id>.alias}
override_workspace = ${apex.<app_id>.workspace}
override_app_id = ${apex.<app_id>.appId}

How to set property values

In Liquibase there is the concept of properties that you can set multiple ways:

Via a properties file
SQLcl command line argument
Directly in the change log (XML/JSON/YAML)
Environment variables

I am going to show point 1 today and may show the other 3 points in the future.

Properties File

Here is my repo after creating my SQLcl Project, exporting, staging, and creating a release. I have one APEX application in my DEV environment with the app ID 100. This will be its unique identifer.

Next, create a properties file. I created one named liquibase.properties and placed in my dist/utils/ folder.

apex.100.alias = NEIL_TEST_APP
apex.100.appId = 12345678
apex.100.workspace = TEST
apex.100.schema = WKSP_TEST

Next modify dist/install.sql and add the -defaults-file utils/liquibase.properties option to your lb update command. This will tell Liquibase to use that file to drive our custom parameter/property values. Below is in example of the modified section in our dist/install.sql

-- Kick off Liquibase
prompt "Installing/updating schemas"
lb update -log -changelog-file releases/main.changelog.xml -search-path "." -defaults-file utils/liquibase.properties

Next generate your artifact. Remember the assumption was that you have already done all the previous steps of exporting, staging, and creating release.

neiferna@neiferna-mac sqlcl_apex_bug % sql /nolog


SQLcl: Release 24.4 Production on Fri Mar 07 09:54:46 2025

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

SQL> project gen-artifact -version 1.0
Your artifact has been generated demo-1.0.zip

Next it is time to deploy!

SQL> conn -name demo
Connected.
SQL> project deploy -file artifact/demo-1.0.zip
Starting the migration...

Voila, it got installed into a different workspace, with a different alias, and a new Application ID.

Future

I have another blog post coming soon that will show you how to add custom scripts to make the installer for APEX installation parameters even more configurable. This will include switching and modifying authentication schemes using substitution values and custom scripts. The example above includes some built-in parameters, and there may be more flexibility in the future.

Command Palette