GitHub PagesからOracle APEXのアプリの静的アプリケーション・ファイルを配信する

以前の記事「LottieのアニメーションをOracle APEXのアプリケーションに表示する」で作成したAPEXアプリケーションに含まれる静的アプリケーションファイルを、GitHub Pagesから配信するように設定します。

GitHub Pagesを使用するための設定については、色々なサイトで紹介されている記事を参照することをお勧めします。作業の参考になるように、GitHub側で実施した作業について簡単に紹介します。

最初にWebサイト名と同じ名前になるリポジトリ<username>.github.ioを作成しました。<username>の部分は、GitHubのユーザー名です。本記事ではリポジトリとしてujnak.github.ioを作成しました。GitHub PagesのWebサイト名は<username>.github.ioになります。Webサイト名と同名のリポジトリに保存されているデータはhttps://<username>.github.io/の直下から参照できるようになります。

GitHubのRepositoriesの画面より、新規にリポジトリを作成します。

Repository nameに<username>.github.ioを設定します。Descriptionには簡単な説明として「GitHub Pages for APEX Static Application Files」を記述しました。保護についてはPublicを選択します。

以上でCreate repositoryを実行します。

リポジトリが作成され、この後に実施すべき作業が表示されます。

手元のPCでの作業に移ります。

作成したリポジトリをクローンします。

git clone https://github.com/<username>/<username>.github.io.git

実行ディレクトリの下にディレクトリ<username>.github.ioが作成されます。

% git clone https://github.com/ujnak/ujnak.github.io.git

% ls

apexapps ujnak.github.io

% 

Lottieのアニメーションを表示するAPEXアプリケーションをアプリケーション・ビルダーで開き、共有コンポーネントの静的アプリケーション・ファイルを開きます。

Zipとしてダウンロードをクリックし、保存されているすべての静的アプリケーション・ファイルをダウンロードします。

ZIPファイルはf<アプリケーションID>_static_application_files.zipとしてダウンロードされます。

ダウンロードした静的アプリケーション・ファイルをリポジトリ<username>.github.ioにplay-lottieというディレクトリを作成し、その下に解凍します。

cd ujnak.github.io
unzip -d play-lottie ~/Downloads/f224_static_application_files.zip

% cd ujnak.github.io

ujnak.github.io % unzip -d play-lottie ~/Downloads/f224_static_application_files.zip

Archive:  /Downloads/f224_static_application_files.zip

Implementation by Anton Scheffer

  inflating: play-lottie/MyFirstLottie.json  

  inflating: play-lottie/MyFirstLottie.lottie  

  inflating: play-lottie/icons/app-icon-144-rounded.png  

  inflating: play-lottie/icons/app-icon-192.png  

  inflating: play-lottie/icons/app-icon-256-rounded.png  

 extracting: play-lottie/icons/app-icon-32.png  

  inflating: play-lottie/icons/app-icon-512.png  

  inflating: play-lottie/js/app-dotlottie.js  

  inflating: play-lottie/js/app-dotlottie.min.js  

  inflating: play-lottie/js/app-lottie.js  

  inflating: play-lottie/js/app-lottie.min.js  

ujnak.github.io % 

VSCodeのLive Serverを起動するため、<username>.github.ioの直下にファイルindex.htmlを作成します。以下のコマンドを実行し、最低限のHTMLを記述します。

echo "<html><body>Hosting Available</body></html>" > index.html

ujnak.github.io % echo "<html><body>Hosting Available</body></html>" > index.html

ujnak.github.io % 

今までに作成したファイルをコミットし、リポジトリにプッシュします。

git add .
git commit -m 'Add Static Files for Play Lottie'
git branch -M main
git push -u origin main

ujnak.github.io % git add .

ujnak.github.io % git commit -m 'Add Static Files for Play Lottie'

[main (root-commit) 45a16c0] Add Static Files for Play Lottie

 12 files changed, 128 insertions(+)

 create mode 100644 index.html

 create mode 100644 play-lottie/MyFirstLottie.json

 create mode 100644 play-lottie/MyFirstLottie.lottie

 create mode 100644 play-lottie/icons/app-icon-144-rounded.png

 create mode 100644 play-lottie/icons/app-icon-192.png

 create mode 100644 play-lottie/icons/app-icon-256-rounded.png

 create mode 100644 play-lottie/icons/app-icon-32.png

 create mode 100644 play-lottie/icons/app-icon-512.png

 create mode 100644 play-lottie/js/app-dotlottie.js

 create mode 100644 play-lottie/js/app-dotlottie.min.js

 create mode 100644 play-lottie/js/app-lottie.js

 create mode 100644 play-lottie/js/app-lottie.min.js

ujnak.github.io % git branch -M main

ynakakoshi@Ns-Macbook ujnak.github.io % git push -u origin main

Enumerating objects: 17, done.

Counting objects: 100% (17/17), done.

Delta compression using up to 16 threads

Compressing objects: 100% (16/16), done.

Writing objects: 100% (17/17), 37.45 KiB | 18.72 MiB/s, done.

Total 17 (delta 2), reused 0 (delta 0), pack-reused 0

remote: Resolving deltas: 100% (2/2), done.

To https://github.com/ujnak/ujnak.github.io.git

 * [new branch]      main -> main

branch 'main' set up to track 'origin/main'.

ujnak.github.io % 

どこかのタイミングでリモート・リポジトリの認証を要求されるかもしれません。今回の作業ではGitHub CLIのgh auth loginを実行し、認証しています。

https://cli.github.com/manual/gh_auth_login

以上でGitHub Pagesより、APEXの静的アプリケーション・ファイルが配信されるようになりました。index.htmlにアクセスして確認します。

https://<username>.github.io/index.html

先ほどindex.htmlに書き込んだHosting Availableの表示が確認できます。

VSCodeを起動し、ローカルのリポジトリ<username>.github.ioを開きます。

index.htmlを選択し、Live Serverを起動します。

Live Serverでは以下のURLより、index.htmlをアクセスできます。

http://localhost:5500/index.html

GitHub Pagesを静的アプリケーション・ファイルの参照先に変更します。

アプリケーション定義のユーザー・インターフェースの詳細にある、#APP_FILES#のパスとして以下を設定します。

https://<username>.github.io/play-lottie/

APEXアプリケーションを実行し、GitHub Pagesが静的アプリケーション・ファイルの参照先となっているか確認します。

JavaScriptコンソールのネットワークを開きます。

lottie-webのページでは、JavaScriptのファイルURLとして以下が設定されています。

[module, defer]#APP_FILES#js/app-lottie#MIN#.js

#APP_FILES#としてhttps://<username>.github.io/play-lottie/を設定しているため、ページが実行されたときにロードされるJavaScriptのファイルは以下になります。

https://<username>.github.io/play-lottie/js/app-lottie.js

置換文字列#MIN#は、開発モードおよびデバッグが有効な場合は空白に置換されます。プロダクションでは.minに置き換わります。

JavaScriptコンソールよりapp-lottie.jsを選択し、リクエストURLとしてGitHub Pagesのファイルを参照していることを確認します。

以上で静的アプリケーション・ファイルの参照先を、データベースからGitHub Pagesに移行することができました。この後はAPEXアプリケーションに保存されている静的アプリケーション・ファイルが参照されることはないため、すべて削除することもできます。

データベースを静的なファイルを配信するために使用するかわりに、コンテンツの配信を行なうサービスを使用する方がコストメリットがあります。ただし、静的なファイルはブラウザでキャッシュされるため、どの程度データベースから負荷をオフロードできるかはアプリケーションに依存します。

この構成でAPEXアプリケーションを開発する場合、静的アプリケーション・ファイルの変更はVSCodeで実施することになります。動作の確認にはセッション・オーバーライドを使用して、Live Serverよりローカルのファイルを参照します。

開発者ツールバーよりセッション・オーバーライドを開き、セッション・オーバーライドの有効化をオンにし、ファイル・パスのアプリケーション・ファイル#APP_FILES#として以下を設定します。

http://localhost:5500/play-lottie/

JavaScriptコンソールでファイルapp-lotttie.jsのリクエストURLが、Live Serverを指していることを確認します。

VSCodeよりファイルapp-lottie.jsを変更します。変更をJavaScriptコンソールから確認できるように、以下の１行を挿入します。

console.log('lottie-web is loaded.');

セッション・オーバーライドを使ってローカルのLive Serverを参照している場合は、上記の変更はページを再ロードすると即座に反映されます。

セッション・オーバーライドを解除するとGitHub Pagesを参照するため、先ほどの変更が行われる前のファイルが参照されます。そのため、追加したconsole.logによる出力は、JavaScriptコンソールに表示されません。

変更をGitHub Pages、つまりリモート・リポジトリに反映させるため、app-lottie.jsの変更をステージし、コミットしてプッシュを呼び出します。

セッション・オーバーライドを外し、キャッシュをリフレッシュする形でアプリケーションを再ロードすると、GitHub Pagesから参照しているapp-lottie.jsに変更が反映されていることが確認できます。

この状態でAPEXアプリケーションをリリースしても、プロダクションに変更は反映されません。プロダクション環境では置換文字列#MIN#が.minに置き換わり、app-lottie.min.jsを参照されるためです。

Oracle APEXの静的アプリケーション・ファイルとして保存される.jsファイルおよび.cssファイルは、スクリプト・エディタでの保存時に自動的にミニファイされます。VSCodeでは拡張機能を使うなどして、VSCode側でミニファイする必要があります。

例えばHookyQRのMinifyといった拡張機能を使用して、ミニファイします。

ミニファイしたファイルの変更をステージし、リモート・リポジトリにコミットとプッシュすることにより、プロダクションに変更が反映されます。

以上でプロダクションのアプリケーションにJavaScriptの変更が反映されました。

今回の記事は以上になります。

最近、制限はありますがVSCodeで無料でGitHub Copilotが使用できるようになりました。

英国在住の著名なAPEX開発者であるMatt Mulvaneyさんが早速、GitHub CopilotのFreeプランを使用した記事を公開しています。PL/SQLのコーディングを対象としています。

VSCode & Copilot Free for PL/SQL

https://mattmulvaney.hashnode.dev/vscode-copilot-free-for-plsql

JavaScript、CSS（APEXでは使わないがPython）などは生成AIが得意な言語なので、APEXのアプリケーション開発もVSCode + CopilotやCursorといったエディタを使うケースが多くなるかもしれません。

完

GitHub、VS Code、APEXのセッション・オーバーライド、DBのエディションを使った開発

APEXアプリケーションを開発していると、フロントエンドに実装するJavaScriptやCSS、またはバックエンドで実行するSQLやPL/SQLを少し変更して、アプリケーションを実行したいということがあります。

APEXアプリケーションにコードを埋め込んでいる場合は、アプリケーションのコピーを作成してコードを改変することで対応できます。ただし、アプリケーションにコードを埋め込んでいると、単体テストはほぼできません。また、そのままでもCI/CDに乗せるのは大変なのに、さらに大変になります。

海外のパートナーさんでは、レポートのソースとして必ずビューを作りSQLの埋め込みは禁止する、PL/SQLは必ずパッケージを作りコードの埋め込みは禁止する、といった開発標準を採用しているところもあります。

以下よりGitHub、VS Code、APEXのセッション・オーバーライド、Oracle Databaseのエディションの機能を使って、バージョンの異なるコードをAPEXアプリケーションで実行してみます。

初期状態のmainブランチ

以下のアプリケーションを作成します。APEXアプリケーションの作成には、Always FreeのAutonomous Databaseを使用します。

上記のアプリケーションのエクスポートは以下にあります。

https://github.com/ujnak/apexapps/blob/master/exports/edition_app.zip

アプリケーションを作ること自体が目的ではないので、作り方は省略します。

ボタンSet Textをクリックすると、テキスト・フィールドTextにThis is MAINという文字列を挿入します。

これは静的アプリケーション・ファイルに作成したアクションset-my-textを呼び出しています。

この静的アプリケーション・ファイルは、ページ・プロパティのJavaScriptのファイルURLに設定しています。

ボタンSET_TEXTの詳細のカスタム属性として以下を記述し、アクションset-my-textを呼び出します。

data-action="#action$set-my-text?target=P1_TEXT"

動的アクションとしても実装できますが、コード埋め込みを避けています。

ボタンSet Editionをクリックすると、テキスト・フィールドEditionにMAINという文字列を挿入します。

これはパッケージTEST_PACKAGEに実装したファンクションSHOW_EDITIONを実行しています。パッケージのソースは以下になります。

このファンクションは、ボタンSET_EDITIONを押したときに実行されるプロセスに設定します。プロセス・タイプはAPIの呼出しです。

パラメータのファンクションの結果をページ・アイテムP1_EDITIONに設定します。

この場合も、コードの埋め込みは避けています。

クラシック・レポートのソースとしてビューEMP_Vを使用します。ビューの定義は以下になります。サンプル・データセットのEMP/DEPTに含まれる表EMPを、そのままビューにしています。

ここでも、直接SELECT文を記述しないようにしています。

ビュー定義にeditonableと付けていますが（デフォルトでeditonableなので付けなくても良い）、エディショニング・ビュー（これにはeditioningと付ける）ではありません。異なるオブジェクト・タイプなので注意が必要です。

以上の３つの実装、フロント・エンドのJavaScript、バックエンドのパッケージTEST_PACKAGE、ビューEMP_Vをブランチmainの実装を維持しつつ、新しくブランチを作って改変してみます。

VS Codeの設定

開発にはVS Codeを使用します。以下の拡張機能をインストールします。

Oracle Developer Tools for VS Code (SQL and PLSQL)

Minify

Live Server

GitHub Repositories

および上記に依存関係のある拡張機能をインストールします。

普段VS Codeを使っていないので、ほとんどの時間はVS Codeの使い方を調べること費やしてしまいました。SQL DeveloperのPMのJeff Smithさんが昨年アナウンスしていた、VS CodeベースのSQL Developerの次世代版が早くリリースされることを祈るばかりです。

VS Codeを使おうと思ったのは、そうすればGitHub Copilotといった生成AIの恩恵に預かるチャンスがあると思ったためです。特にSQLのSELECT文は、生成AIと相性が良いように思います。PL/SQLはマイナーな言語なので恩恵は少なそうですが、DB 23cからはサーバー側もJavaScriptでコーディングできます。

接続先をAutonomous Databaseとした場合、インスタンス・ウォレットのファイルをダウンロードします。ダウンロードしたウォレットはWallet_インスタンス名.zipとなります。このZIPファイルを展開すると、以下のようにTNSエイリアスが定義されているtnsnames.ora、および自動ログイン・ウォレット・ファイルcwallet.ssoが含まれています。

APEXDEV2 % ls -l

total 96

-rw-r--r--@ 1 **********  staff  3029  5 16 06:23 README

-rw-r--r--@ 1 **********  staff  6701  5 16 06:23 cwallet.sso

-rw-r--r--@ 1 **********  staff  6656  5 16 06:23 ewallet.p12

-rw-r--r--@ 1 **********  staff  7475  5 16 06:23 ewallet.pem

-rw-r--r--@ 1 **********  staff  3190  5 16 06:23 keystore.jks

-rw-r--r--@ 1 **********  staff   691  5 16 06:23 ojdbc.properties

-rw-r--r--@ 1 **********  staff   114  5 16 06:23 sqlnet.ora

-rw-r--r--@ 1 **********  staff  1290  5 16 06:23 tnsnames.ora

-rw-r--r--@ 1 **********  staff  3378  5 16 06:23 truststore.jks

APEXDEV2 % 

TNS Admin LocationおよびWallet File Locationに、Wallet_インスタンス名.zipを展開したディレクトリを指定します。また、Use Wallet File（ここでいうWallet Fileはcwallet.ssoのこと）にチェックを入れます。

接続に使用するユーザー名（User name）およびパスワード（Password）は、APEXのワークスペース・スキーマのものを指定します。

APEXのワークスペースを作成した時点では、ワークスペース・スキーマは外部から接続できるように構成されていません。

ワークスペース・スキーマWKSP_APEXDEVにパスワードを設定し、RESTfulサービスを有効化する必要があります。

alter user wksp_apexdev identified by <パスワード>;
begin
ords_admin.enable_schema(
p_schema => 'WKSP_APEXDEV'
);
end;
/

SQL> alter user wksp_apexdev identified by <パスワード>;

User WKSP_APEXDEVが変更されました。

SQL> begin

  2  ords_admin.enable_schema(

  3  p_schema => 'WKSP_APEXDEV'

  4  );

  5  end;

  6* /

PL/SQLプロシージャが正常に完了しました。

SQL> 

以上の設定で、Oracle Developer Tools for VS Codeの拡張機能を使って、Autonomous Databaseに接続できるようになります。

ブランチed_hanakoとエディションED_HANAKOの準備

ブランチとしてed_hanakoを作成し、ブランチmainのアプリケーションを修正します。

ブランチの名前をed_hanakoとします。

これ以降のGitHubへのコミットが、ブランチed_hanakoに対して行われるようになりました。

APEXアプリケーションをホストしているAutonomous Databaseに、管理者ユーザーADMINで接続します。APEXのワークスペースのスキーマがWKSP_APEXDEVと仮定します。

以下のコマンドを実行し、スキーマをエディションを有効にします。

alter user wksp_apexdev enable editions;

SQL> alter user wksp_apexdev enable editions;

User WKSP_APEXDEVが変更されました。

SQL> 

エディションED_HANAKOを作成し、スキーマWKSP_APEXDEVで利用可能にします。

create edition ed_hanako as child of ora$base;
grant use on edition ed_hanako to wksp_apexdev;

SQL> create edition ed_hanako as child of ora$base;

Edition ED_HANAKOは作成されました。

SQL> grant use on edition ed_hanako to wksp_apexdev;

Grantが正常に実行されました。

SQL> 

Oracle Developer Tools for VS CodeでのAutonomous Databaseの接続情報に、ログイン・スクリプト（Login Script）を設定します。

ログイン・スクリプトとして指定するファイルには、以下の行を含めます。データベース接続時にエディションをED_HAHAKOに設定します。

alter session set edition = ED_HANAKO;

作成されているAPEXアプリケーションのコピーを作成し、エディションED_HANAKOで動作するように設定します。アプリケーションのコピーはタスクから実行します。

花子さん用のアプリケーションということで、新規アプリケーション名をEdition App (hanako)とします。

次へ進みます。

アプリケーションのコピーを実行します。

アプリケーションが作成されたら、アプリケーション定義のセキュリティのデータベース・セッションを開きます。

初期化PL/SQLコードとして以下を記述します。APEXのページ・プロセスは常に、エディションED_HANAKOで動作するようになります。

begin
    apex_util.set_edition('ED_HANAKO');
end;

フロントエンドのJavaScriptの修正

APEXアプリケーションには５つの静的アプリケーション・ファイルが含まれており、ボタンSet Textで実行されるアクションはactions.jsに記述されています。

GitHubリポジトリのローカル・コピーでは、ディレクトリfrontend以下にactions.jsを作成しています。

 EditionApp % ls -lR frontend 

total 16

-rw-rw-rw-@ 1 **********  staff  415  5 17 00:33 actions.js

-rw-rw-rw-@ 1 **********  staff  179  5 17 10:29 actions.min.js

drwxr-xr-x@ 5 **********  staff  160  5 17 09:34 icons

frontend/icons:

total 40

-rw-rw-rw-@ 1 **********  staff   2076  5 17 00:33 app-icon-192.png

-rw-rw-rw-@ 1 **********  staff    347  5 17 00:33 app-icon-32.png

-rw-rw-rw-@ 1 **********  staff  10219  5 17 00:33 app-icon-512.png

 EditionApp % 

Live Serverを起動するために、ディレクトリfrontend以下にファイルindex.htmlを作成します。以下の内容を記述します。

<html><body>Hanako</body></html>

作成したindex.htmlを対象にして、Live Serverを起動します。

HTTPサーバーがローカルホストの5500番ポートに起動し、index.htmlおよびactions.js、actions.min.jsといったファイルへアクセスできるようになります。

http://127.0.0.1:5500/frontend/index.html

コピーしたアプリケーションにアクセスします。

Current Edition NameがED_HANAKOであることを確認します。続いて開発者ツール・バーのセッションより、セッション・オーバーライドを実行します。

セッション・オーバーライドの有効化をオンに変更します。

ファイル・パスのアプリケーション・ファイル#APP_FILES#をオンに変更し、Live ServerのURLであるhttp://127.0.0.1/frontend/を設定します。

以上の変更を行い、保存します。

VS Codeでactions.jsを変更します。This is MAINをThis is HANAKOに書き換え、保存します。

Command+Shift+P（macOSの場合）を入力しコマンド・パレットを表示し、Minifyを実行します。actions.jsからactions.min.jsを生成します。APEXアプリケーションではデバッグ・モードでない場合はミニファイされたファイルにアクセスします。

ミニファイされたファイルactions.min.jsも変更されたことを確認します。フラグがMに変わります。

アプリケーションをリロードし、ボタンSet Textをクリックします。

テキスト・フィールドTextにThis is HANAKOと表示されることを確認します。

この変更は、オリジナルのアプリケーション（ブランチmain、エディションORA$BASE）には影響を与えていません。

拡張機能のソース管理を開き、actions.jsとactions.min.jsをステージします。＋サインをクリックします。

メッセージを入力して、変更をコミットします。

JavaScriptのコードの修正についての説明は、ここまでにします。

バックエンドのPL/SQLパッケージの修正

接続済みのOracle Databaseを選択し、Open New SQL Fileを呼び出します。

以下のSELECT文を実行し、設定されているエディションを確認します。

SELECT SYS_CONTEXT('USERENV', 'CURRENT_EDITION_NAME') FROM DUAL;

結果がED_HANAKOであることを確認します。

ディレクトリbackend以下のtest_package.sql（本当は拡張子は.plbにしたかったのだけど、どうしてもVSCodeで上手く扱えなかったので.sqlにしています）を開きます。

ファンクションSHOW_EDITIONの戻り値をMAINからHANAKOに変更し、ファイルを保存します。

接続済みデータベースを選択し、Open Existing SQL Fileを呼び出します。

パッケージ定義test_package.plsを開き、スクリプトを実行します。

実行結果にエラーがないことを確認します。

同様にパッケージ本体test_package.sqlを開き、スクリプトの実行を行います。

なぜかNot connectedというエラーが発生することがあります。再度実行すると成功するので、原因はよくわかりません。

以下のコードを実行し、コードの変更を確認します。

begin
    dbms_output.put_line(test_package.show_edition);
end;

結果がHANAKOであれば、エディションED_HANAKOでのパッケージの変更は完了です。

エディションHANAKOで動作するアプリケーションを使って、パッケージの変更を確認します。

ボタンSet Editionをクリックすると、EditionにHANAKOと表示されます。

オリジナルのアプリケーションは影響を受けません。

パッケージの修正は以上になります。

バックエンドのビューEMP_Vの修正

パッケージの修正と同じ作業になります。

Open Existing SQL Fileを呼び出しemp_v.sqlを開きます。

ビュー定義に条件句を追加し保存します。その後、スクリプトを実行します。

create or replace editionable view emp_v
as
select * from emp
where deptno = 10;

エディションHANAKOで動作するアプリケーションのページをリロードします。レポートの表示が変わっていることを確認します。

ビューの修正は以上になります。

複数のブランチ/エディションを使う

例えば太郎さんのためにブランチed_taroを作成します。これはブランチmainから派生させます。GitHub側は特別な操作ではありませんが、データベースのエディションの扱いは難しい部分があります。

Oracle Databaseのエディションは、親となるエディションに作成できる子のエディションは１つという制約があります。また、エディションの削除はリーフとなるエディション、つまり最後のエディションしか削除できない、という制限があります。

今までの作業を継続してエディションED_TAROを作成するために、GitHubのブランチmainからed_taroを作成したように、ベース・エディションであるORA$BASEから作成しようとすると、以下のようなエラーが発生します。

SQL> create edition ed_taro as child of ora$base;

次のコマンドの開始中にエラーが発生しました : 行 1 -

create edition ed_taro as child of ora$base

エラー・レポート -

ORA-38807: 実装制限: エディションが持てる子は1つのみです

38807. 00000 -  "Implementation restriction: an edition can have only one child"

*Cause:    This error occurred because an attempt was made to create more

           than one child edition for a parent edition.

*Action:   Create the edition as a child of the leaf edition.

SQL> 

そのため、エディションED_TAROはED_HANAKOの子エディションとして作成する必要があります。

create edition ed_taro as child of ed_hanako;

SQL> create edition ed_taro as child of ed_hanako;

Edition ED_TAROは作成されました。

SQL> 

ワークスペース・スキーマにエディションED_TAROを利用する権限を与えます。

grant use on edition ed_taro to wksp_apexdev;

SQL> grant use on edition ed_taro to wksp_apexdev;

Grantが正常に実行されました。

SQL> 

エディションED_TAROで接続してビューEMP_Vを検索すると、親のエディションであるED_HANAKOでの定義が使用され、deptno = 10の条件が適用されます。

ブランチed_taroはmainから派生しているため、ファイルemp_v.sqlにはdeptno = 10の条件は付いていません。

そのため、親のエディション（ベース・エディションであるORA$BASE以外）でオブジェクト定義が変更されているものは、対応するSQLファイルを実行してベース・エディションで定義されているオブジェクトを作成する必要があります。

実際にはどのオブジェクトが変更されているか見つけにくいので、DDLであるSQLファイルはすべて実行することになると予想されます。

また、エディションED_HANAKO（ブランチとしてはed_hanako）を削除するには、以下のような手順になります。

リーフ・エディションのED_TAROを削除し、続いてED_HANAKOを削除します。そしてED_TAROを再度作成します。エディションED_TAROを作成したのち、ブランチed_taroにあるSQLファイルをすべて実行し直し、そのブランチのパッケージやビューを作り直します。

SQL> drop edition ed_taro cascade;

Edition ED_TAROが削除されました。

SQL> drop edition ed_hanako cascade;

Edition ED_HANAKOが削除されました。

SQL> create edition ed_taro as child of ora$base;

Edition ED_TAROは作成されました。

SQL> grant use on edition ed_taro to wksp_apexdev;

Grantが正常に実行されました。

SQL> 

ページ・デザイナはエディション非対応

ページ・デザイナを含むOracle APEXの開発ツールはエディションに対応していないため、つねにORA$BASEで動作します。

ビューやパッケージの新規作成、ビューの列数の変更、パッケージのサブプログラムの追加、引数の変更などは、ベースであるエディションORA$BASEで実施する必要があります。

その他

スキーマに対してエディションを有効にすると、元に戻すことができません。また、11gから実装されている機能とはいえ、事例が豊富ということは無いようです。環境として、テスト、ステージ、本番があるときに、エディションを活用するのはテスト環境に限定した方が良いように思います。

完