ライオンキング見てきました。

ミュージカルという感じではないですね。
分類とかはよく分らないですが、CATSはまさに
ミュージカルって感じでしたがその感覚で見ると
ライオンキングはミュージカルではないって気がします。

きっと構成的なものなんでしょうね。
CATSは音楽、歌に合わせて人が動くのに対し
ライオンキングは人に合わせて音楽、歌が流れる感じです。
ライオンキングはストーリー重視って感じかな。
そういう特性のおかげかライオンキングでは笑いがありましたね。

ネタバレな部分もあるのであとは続きで。

つづきはこちら

SQLローダーはファイルの中身をテーブルに
そのまま突っ込む時に使うoracleの付属ツールです。
コマンドでsqlldrって叩くと使えます。

ファイル形式は色々なものに対応しているようですが、
主にcsvファイルを取り込むケースが多いと思います。
csvゆうてもカンマ区切りやタブ区切り、
ダブルコーテーションで括られているかそうでないか、
先頭行にヘッダ行があったりなかったりと
色々種類があります。

けど、SQLローダーはそこら辺も考慮された物になっています。
そういう細かい指定を制御するのがctlファイルと
呼ばれるファイルです。
通常はsqlldrコマンドの引数でこのファイルを指定する事に
なると思います。

ctlファイルの主な使い方は探せば簡単に見つかります。
なのでここでは見つけにくかった事を書きます。
ctlファイルでの指定では基本的にcsvの先頭から順に
テーブルのカラムを割り当てていきます。
ところが、csvにも取り込みたくないカラムが存在する事も
あるかと思います。（備考とか？）
その時の指定は
適当な名前 FILLER
です。
適当な名前の部分はホントに適当なものでいいようです。
大事なのはFILLERの方です。
これを指定するとcsvの現在のカラムはスキップされるようです。
一度覚えてしまえば後はこのキーワードで検索すれば
更に色々と情報が得られると思います。
けど、最初の取っ掛かりがないと中々調べるのも時間がかかります。
というかかかりました。

SQLローダー使ってみた感じ、結構楽ですね。
ctlファイルを書かなければいけないのは面倒ですが、
ダブルコーテーションの有無が混在していたりするものだと
特に効果的だと思います。

struts1.3.8でファイルアップロードを実装しました。
web.xmlのcontrollerでファイル上限値を設定ました。
多くのサイトでは上限値を超えたファイルが
アップロードされた場合に例外が発生すると
書かれてた（気がする）けどそうはなりませんでした。

具体的には何も起きませんでした。
何も起きないというかスルーされてる感じ？
1回ファイルアップロードを行い（上限未満）、
再度上限を超えるファイルをアップすると
formの中身は2回目の内容が全く設定されません。
だけど普通にActionまで来ちゃうので前回のformの
内容でActionが動いちゃいます。

色々と調べて最終的にはstrutsのソースを見て解決しました。
元々そうだったのか、それとも最近のバージョンで
変わったのかは分りませんが、例外は出ないようです。
その代わり、requestのattributeにファイル上限を
超えた事が分る目印が付けられていました。
MultipartRequestHandler.ATTRIBUTE_MAX_LENGTH_EXCEEDED
だったかな。

なのでForm.validateとかActionとかでこれを判定して
エラー処理する事になるようです。
知らなかったので結構はまりました。

LDAPを使う必要性が出てきました。
実はLDAP自体は結構前にチラッと調べた事が
あったりします。
ただの興味本位って程度でしたけどね。
なのでディレクトリの概念ぐらいは事前知識として
持った状態で触ってます。

概念は分るものの設定が実はかなりムズイです。
スキーマというものがあり、LDAPのサービス起動時に
*.schemaというファイルが読み込まれます。
このスキーマファイルで定義したものが項目として
選べるという仕組みになっているようで、
好き勝手にディレクトリの名前を設定できる訳ではないようです。

スキーマはよく使われる物が集められたものが
デフォルトでロードされますが、
それ以外に自分で定義するカスタムスキーマも使えます。
なので好きな名前を使うにはまずこのスキーマを定義しないと
いけないようです。

スキーマの定義はクラスの概念に近い感じで
継承関係とかabstractな定義とかが出来たりします。
structとかattributeもあるのでこれを駆使すれば
簡単に定義できそうな感じがするのですが、
ところがこの定義はスゴイ癖があるようです。
継承関係がおかしいんですよね。

ルートはJavaだとObjectですが、スキーマの場合は
topがルートのようです。
で、色々な定義が予め用意されているのですが、
他のスキーマで定義したものがカスタムスキーマで
継承できなかったりするのです。
ロード順とかの問題かもしれませんが、
色々調べたけど結局解決できていない問題だったりします。

という事でLDAPであれこれ定義すべきではないかな〜
というのが感想です。
LDAPの動作自体は早いものらしいので利用できる部分は
利用した方がいいと思いますが、カスタムでなんとかする
というのは余り向いてないのかもしれません。
データはテキストファイルで入出力できるので
バックアップとかリストアとかはお手軽に出来るので
そういう面はすごくメリットがあると思います。

使ってみました。
結構便利ですね。

前他の人が使ってるのを見てて、その時は動作が重くて
使い物にならないって思ってたけど作るの自体は直ぐできちゃいます。
色々な痒いところに手が届くので短いコーディングで
色々できるのが利点ですね。