PEXA Modelについて

チュートリアル

定義ファイル

機能一覧

リファレンス
目次
  1. SQLユーザ関数の利用について
  2. Model定義の記述方法
  3. DBベンダにおけるユーザ関数の対応
  4. SQLストアードプロセジャの利用について
  5. SQLストアードプロセジャModel定義の記述方法
  6. ストアードプロセジャ作成注意点
  7. 各DBベンダにおけるストアードプロセジャの対応
  8. APサーバーの起動環境変数について


SQLユーザ関数の利用について

単純サーチで、カラム名にSQLユーザ関数(SQL function)を使用することができます。
Model定義では通常現象型名とカラム名をcolumnセクションで記述します
これを現象型名とSQLユーザ関数名＋パラメータ（必要な時のみ）として記述します。
ReminderAlertCount "func100(UNDO_PTYPE_NO)" func100がSQLユーザー関数定義になります。

SQLユーザ関数のパラメータとして、同一DBテーブルのカラムを指定することが出来ます。
サーチ時の取得現象型のほか、検索項目の現象型としても指定することが出来ます。
サービスでは特に意識する必要はありません。
DB内のテーブルから情報を取れるものは、Model定義のプロセジャーセクションではなく、SQLユーザ関数に置き換えることが可能となります。
よって、プロセジャーの検索項目はextra_filterに指定する必要がありましたが、該当機能を使用するモデル内の現象型はfilterで指定することができ、APサーバーの負荷を低減することが可能です。（DBサーバーの負荷は上がります）
SQLユーザ関数を定義したモデル現象型は書込みはできません。
SQLユーザ関数は事前にDBに登録してから実行してください。


ユーザ関数Model定義の記述方法

Model定義のloadセクションで以下のようにSQLユーザ関数を指定します。

	記述例:ReminderAlertCount部分がSQLユーザー関数
	LastUpdator		LAST_UPDATOR
	LastUpdateDatetime	LAST_UPDATE_DATETIME
	ReminderAlertCount	"func100(UNDO_PTYPE_NO)";この部分がSQLユーザー関数定義になります。
	Remover			REMOVER
SQLユーザ関数は事前にDBに登録してから実行してください。
loadセクションのみに記述し、save/createセクションには記述しないでください。
SQLユーザ関数には（）があるので、SQLユーザ関数はダブルコーテーション“で囲んで記述する必要があります。


DBベンダにおけるユーザ関数の対応 

SQLユーザ関数の作成･文法はDBベンダごとに異なります。

Oracleでのユーザ関数の対応

Oracleを基準としています。

記述例：
CREATE OR REPLACE FUNCTION FUNC100(UNDONO IN INT) RETURN INT AS
 RCOUNT INT;
BEGIN
	SELECT COUNT(*) INTO RCOUNT 
		FROM UNDO_PTYPE_DETAIL_MODEL  
			WHERE UNDO_PTYPE_NO = UNDONO 
				AND REMOVED_FLAG = 0;
	RETURN (RCOUNT);
END FUNC100;


PostgreSQLでのユーザ関数の対応

OracleとはRETURNS句が違います。
DECLARE句を指定する必要があります。

記述例：
CREATE OR REPLACE FUNCTION FUNC100(UNDONO IN INT) RETURNS INT AS $FUNC$
DECLARE
 RCOUNT INT;
BEGIN
	SELECT COUNT(*) INTO RCOUNT 
		FROM UNDO_PTYPE_DETAIL_MODEL  
			WHERE UNDO_PTYPE_NO = UNDONO 
				AND REMOVED_FLAG = 0;
	RETURN RCOUNT;
END ;
$FUNC$ LANGUAGE plpgsql;
$FUNC$から$FUNC$までがユーザ関数の内容
言語としてPL/PGSQLが登録している必要があります。
		CREATE LANGUAGE plpgsql;


MySQLでのユーザ関数の対応

文法はPostgreSQLと同じですが、ユーザ関数を登録する方法が違います。

記述例：ソースのユーザ関数削除を含むSQL文
DROP FUNCTION IF EXISTS FUNC100;
delimiter //
CREATE FUNCTION FUNC100(UNDONO INT) RETURNS INT
BEGIN
DECLARE RCOUNT INT;
	SELECT COUNT(*) INTO RCOUNT 
		FROM UNDO_PTYPE_DETAIL_MODEL  
			WHERE UNDO_PTYPE_NO = UNDONO 
				AND REMOVED_FLAG = 0;
	RETURN RCOUNT;
END;
//
ユーザ関数SQL定義の終了を示すために
delimiter //
を指定し、最後のEND;の後に
//
を記述する必要があります。



SQLストアードプロセジャの利用について

DBストアードプロセジャをモデルとして定義し実行します。
モデルに対するcreate時のみストアードプロセジャを実行します。
サービスにおいてはmappingプロセスでcommit trueのときに動作します。

(Copy
	format_type	mapping
	(mapping
		create 	force
		commit	true
		(@DA:XTestProc
			UndoPtypeID	"FFFFF"
			RemovedDatetime @NOW
		)
	)
)
save時、load時は例外を発生するので、実行しないでください。
サービスにおいてはsearchプロセスとして実行は出来ません。
PEXAではテーブル情報のチェック時にテーブルとして登録されていない時は、DBストアードプロセジャではないかと
チェックするようなロジックになっていますので、テーブル名と同じストアードプロセジャ名は使用できません。
SQLストアードプロセジャは事前にDBに登録してから実行してください。


SQLストアードプロセジャModel定義の記述方法

一般のモデルと同じような振る舞いをするので、Primaryセクションにプロキシーを指定する必要があります。
よって、カラムセクションにも指定プロキシーをセットします。
ということは、DBストアードプロセジャのパラメータには、指定プロキシーを指定する必要があります。

このモデルで検索は出来ませんが、createセクションのみではなく、loadセクションも記述する必要があります。
テーブル句がストアードプロセジャ名になります。
createセクションがストアードプロセジャのパラメータの情報となります。

context_default     true
check_value         false
pool_name           java:comp/env/jdbc/pexaPool
resource        XTestProc
(schema
    table STEST001 
    (primary
        column		A1
        phenomenon_type	UndoPtypeModelNo
    )
    (column
        (load
            UndoPtypeModelNo       A1
            UndoPtypeID            C1
            ValidityFlag           VALIDITY_FLAG
            RemovedFlag            REMOVED_FLAG
            VersionNumber          VERSION_NUMBER
            RemovedDatetime         REMOVE_DATETIME
        )
        (create
            UndoPtypeModelNo       A1
            UndoPtypeID            C1
            ValidityFlag           VALIDITY_FLAG
            RemovedFlag            REMOVED_FLAG
            VersionNumber          VERSION_NUMBER
            RemovedDatetime        REMOVE_DATETIME
        )
        (save
        )
        (remove
        )
        (delete
        )
    )
)
(procedure
)
(static
    VersionNumber	1
    ValidityFlag	VALID
    RemovedFlag		NOT_REMOVED
    EntityName		XTestProc
)


ストアードプロセジャ作成注意点

ストアードプロセジャではパラメータにINOUTを指定できるが、PEXAではINのみをサポートしています。
PEXA側からストアードプロセジャに対するデータセットのみです。
ストアードプロセジャでOUTの指定をしても、PEXA側に値を渡す機能はありません。
ストアードプロセジャがストアードファンクション（OracleでのFunction・SysbaseでのProcedure）の時は、
戻り値が特別な現象型（PEXA_StoredFunctionReturnValue）に格納されてサービスに戻ります。 PEXA_StoredFunctionReturnValueはjava.lang.Integerになっています。
PEXA_StoredFunctionReturnValueはモデル定義に含める必要はありません。
Pexaモデルフレームワークが戻り値を自動的に格納します。


各DBベンダにおけるストアードプロセジャの対応

ストアードプロセジャはDBベンダごとに記述方法が微妙に違いますので、
各ベンダのマニュアルを参考に記述する必要があります。
PostgreSQLでは現在ストアードプロセジャーがサポートされていません。

Oracleでのストアードプロセジャの対応 

	
記述例：ストアードプロセジャ
CREATE OR REPLACE PROCEDURE STEST001 (
	A1 IN INT,
	C1 IN VARCHAR2,
	VERSION_NUMBER IN INTEGER,
	REMOVED_FLAG IN INTEGER,
	VALIDITY_FLAG IN INTEGER,
	REMOVE_DATETIME IN TIMESTAMP) AS
BEGIN
	INSERT INTO LOGX VALUES(A1,C1,REMOVE_DATETIME);
END;
記述例：ストアードファンクション
CREATE OR REPLACE FUNCTION STEST001FUNC (
	A1 IN INT,
	C1 IN VARCHAR2,
	VERSION_NUMBER IN INTEGER,
	REMOVED_FLAG IN INTEGER,
	VALIDITY_FLAG IN INTEGER,
	REMOVE_DATETIME IN TIMESTAMP) RETURN INTEGER AS
BEGIN
	INSERT INTO LOGX VALUES(A1,C1,REMOVE_DATETIME);
	RETURN 234;
END;


MySQLでのストアードプロセジャの対応

Oracleと比較するとAS句がありません。
パラメータの入出力定義の位置が違います。

記述例：ソースのストアードプロセジャ削除を含むSQL文
DROP PROCEDURE IF EXISTS stest001;
delimiter //
CREATE  PROCEDURE STEST001 (
	IN A1  INT,
	IN C1  VARCHAR(20),
	IN VERSION_NUMBER INT,
	IN REMOVED_FLAG INT,
	IN VALIDITY_FLAG INT,
	IN REMOVE_DATETIME TIMESTAMP)
BEGIN
	INSERT INTO LOGX VALUES(A1,C1,REMOVE_DATETIME);
END;
//
ストアードプロセジャSQL定義の終了を示すために
delimiter //
を指定し、最後のEND;の後に
//
を記述する必要があります。
ちなみにLOGという名称のDBテーブルはMySQLでは作成できません。


Sybaseでのストアードプロセジャの対応

Sybaseはストアードプロセジャはなく、ストアードファンクションのみのサポートとなります。

記述例：
create proc ST_CATTIE @PCATTIENO BIGINT, @VERSION_NUMBER INT, @VALIDITY_FLAG INT, 
                      @REMOVED_FLAG INT, @LAST_UPDATE_DATETIME DATETIME, @LAST_UPDATOR BIGINT
    as
    begin
        update ZDNAAORDERLOG
          set
            LAST_UPDATE_DATETIME = @LAST_UPDATE_DATETIME , LAST_UPDATOR = @LAST_UPDATOR
        return 12345
    end
Sybaseのストアードファンクションのパラメータ名は、先頭に@が必ず付きますが、Pexa内で、@を外した名称で扱います。



APサーバーの起動環境変数について

DBカラム名の大文字･小文字表記やダブルコーテーションの存在などDBベンダーによって違いがあります。
よって、DBベンダーによって、環境変数を変える必要があります。
関連する環境変数は以下の４種類です。

  • db.metainfo
    データベースメタ情報の取得方法
    SQLユーザ関数及びSQLストアードプロセジャを使用するときは必ず、tableを指定する必要があります。(Sybaseを除く)
  • db_sensitive
    DBテーブル名・DBカラム名の大文字・小文字変換
    DBベンダによって、小文字で定義しても大文字に自動的に変換されることがあるので、DBベンダごとに指定する必要があります。
  • column_quote
    DBベンダによって、カラム名のダブルコーテーションの使用が出来ないものがありますので、DBベンダごとに指定する必要があります。
  • db_vendor
    PostgreSQL,Sybaseは、カラム名にテーブル名を連結する等でエラーになるのでその対策のために指定します。他のDBベンダでは記述する必要はありません。
  • db.storedprocedure_prefix
    ストアードプロセジャのモデル名の接頭語を指定します。db.metainfoがtable以外のときも接頭語が等しいモデルは強制的にデータベースからメタデータを取得します。

Oracleでの定義例 

db.metainfo=table
db_sensitive=upper


PostgreSQLでの定義例 

db_sensitive=lower
db.metainfo=table
column_quote=false
db_vendor=POSTGRESQL


MySQLでの定義例 

db_sensitive=lower
db.metainfo=table
column_quote=false


Sybaseでの定義例 


db.storedprocedure_prefix=SPModel
# SPModelにはストアードプロセジャのモデル名の接頭語を指定します。
db_vendor=sybase



更新情報

  • 最終更新者 : $Author: tann $
  • 最終更新日時 : $Date:: 2013-01-18 13:44:04 #$
  • バージョン : $Revision: 7224 $
Copyright © 2006, Atrris Corporation