スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Eclipse 3.01を入れてみた

久しぶりにブログに投稿する。
最初は投稿熱があって書くネタがあれば投稿していたのだが、忙しさもあって放置状態になっていた。先週は仕事のほうも忙しく、トラブル発生で徹夜作業も。
ここ最近の訪問者数を見ると不思議なことに、いや、これが普通なのか?、毎日のように投稿していたころと全く変わっていない。同じ人が見に来てくれているのかどうか、無料のオプションではわかりようがない。Googleにもヒットする。でも増えてはいないな。


ところで、暇を見つけては、自分の趣味というか勉強というか、将来の仕事のためというか、で少しずつProjectを進めている。
Eclipse2.1+Struts1.1+Tomcat5.5で進めていたのを、
Eclipse3.01+Struts1.2+Tomcat5.5に移し変えた。

理由は、Eclipseはバージョン3の方がいろいろと高機能だから。Beanを作成する際に、setter, getterは前から自動生成できたが、3.0からはコンストラクタも自動生成できるようになった。
躊躇していたのはまだプラグインの多くが対応していなくて、また新しいものにつき物の不具合が多いのではと思ったからだ。
しかし、リリースから結構時間もたってきたし、いいだろうと思い、移し変えた。別のディレクトリに3.01を入れ、旧バージョンのworkspaceからインポートすると簡単に移行できた。Tomcatのプラグインも問題なく動く。ただSolarEclipseは表示はできるが、保存ができない。開発も止まっているようだ。ただstrutsのプロパティファイルを自動的に変換するために残している。これだけのためなら他にもプラグインはあるだろうが。XML,JSPについては代わりにHTML Editorを入れた。これにはGEFを一緒に入れる必要がある。悪くはない。あとはJadClipse。これだけでとりあえずのところ十分なので、他に入れていたプラグインは後回し。

結構、快適だ。
Strutsも1.2にしたが、validatorのbundle属性を消したぐらいで他は問題ない。参考にしていた本が、1.1だったのでそのまま使っていたが、ドキュメントやソースを探してくるのが大変だった。strutsのサイトに行くと、最新版しかダウンロードできないし、ドキュメントを一括でダウンロードできない。どうやって探してきたか忘れたが、デバッグ実行の際、ソースの参照箇所が合っていなかったので、たまらず最新版に変えた。
とりあえず順調。

スポンサーサイト

MySQL Reference Key

今日もMySQLをいじってみた。
なぜか、参照制約が効いていない。create文でエラーにはならない。
いろいろ調べているうちに、テーブル生成時にtype=innodbを指定しないといけないことがわかった。一度createしてから、alter文でtypeを変えてもなぜか反映されない。

これで参照制約が有効になったはいいが、困ったことがあった。同一のテーブルへの参照制約をはっている場合、truncateができない。参照制約ではねられてしまう。deleteはむろんだめ。

ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails

JUnitでtruncateとinsertを最初に行って初期設定をするのだが、これができない。制約を無効にしようとしたり、削除しようとしたのだが、いまいちやり方がわからない。
仕方がないので、一文一文逆順に削除するすることにした。ふーっ。
試しにOracleで同じことをやってみたが、当然のごとくあっさりtruncateされて消えた。

あと、auto_incrementもなぜか0からスタートできない。1から始まってしまう。0をadmin用のレコードにしたかったが、うーん、プライマリーキー自体に意味を持たせるのがよくなかったか。

なんちゅう糞DBかと思う。これはただ単に私が知らないだけ?
しかし、下手にOracleに慣れてしまっていると、それと同じことができるだろうなんて期待してしまう。やっぱりOracleは優れていると言いたくなってしまう。
うーん、どっちが悪いんだろう。


MySQL FetchSize

アプリケーションでDBを検索して、その件数が多い場合に、ページに表示する件数を制限して、「前へ」「次へ」とやってページを分けるのはよくある。簡単なようで結構ややこしい。

それをどう実現するかだが、方法としては、
1. 全件取得
 DBから全件持ってきて、それをセッションに保持しておいて、ユーザがリクエストしたタイミングで、たとえば30件ずつ表示していく。この場合、1回のDBアクセスで、前後ページに移動する分のデータはすでにあるので、何度もDBにアクセスしなくて済むというメリットがあり、また簡単にできる。
 しかし、これだと、一行のサイズや件数が多いとかなりメモリを消費する。またユーザごとに検索条件が違う場合、かつユーザが同時にアクセスすればさらに消費する。これは確実にOutOfMemoryになる。

2. キー全件取得
 次にキーのみを全件持ってくる方法だ。そしてたとえば次へを押したら、次の30件分のキーをつけてDBを検索する。これは1に比べるとキーだけの分メモリの消費は少なくて済し、またコーディングも楽である。ただし、莫大な件数があるとこれまた問題である。
 この場合、DB上にワークテーブルを作ってキーを格納してしまうという方法で問題を解決できる。

3. TOPn分析(Oracle)
Oracleであればrownumを使って、DBから取得する件数を制限できる。これだとメモリ消費の問題はない。しかし、境界線の問題がややこしいし、途中で追加、削除があると、前に戻ったとき、件数を合わせるのが大変だったりする。

4. JDBCの標準機能
ResultSet#absolute()などのメソッドを使う。

5. JDBCドライバ固有の機能を使う

実際、Oracleを使うことが多かったので、3でほとんどやっていたが、4のやり方はやったことがなかった。ここのサイトでDbUtilを使ったやり方が書いてあった。

MySQLを使ってやろうと思ったが、まず、ResultSetの取得で、カーソルを回して、順次持ってきているかどうか確認したかったので、以下のようなソースで確認してみた。

stmt.setFetchSize(1);
でフェッチサイズをセットして、

while (rs.next()) {
 System.out.print("OK");
 br.readLine();
System.out.print(rs.getString(1)) ;
}

一個一個確認しながら先に進めていく。アプリケーションからだけではわからないので、DBとアプリを別々のマシンにして、etherealでネットワーク通信のところをキャプチャーして、1回1回通信を行っているか確認する。
MySQLの場合、全くFetch Sizeが機能していない。1だと少なすぎたかと思い、増やしてみたがだめ。1万件のテストデータを作ったが、一度に全件持ってきてしまう。
Oracleで試してみると、きちんと指定した数ずつデータを持ってきている。

MySQL Forumを見てみると、

There is the beginnings of this support in MySQL-5.0,

だなんて書かれている。この手はMySQL 4系では無理か。
では、rownumはどうか。どうやら方法はある。

set @rownum := 0;
select @rownum := @rownum + 1, foo from bar where @rownum < 30;
という風にすればよさそうだ。
MySQLだとOracle同様、from句にselect文を書けるので
select * from
(select @rownum := @rownum + 1 as rank, foo from bar)
where rank between 30 and 60;
とすると任意の間隔で取れそうだ。
(ただOracleでもそうだが、単純にrownumを使うと、間に追加、削除があると厄介なことになる。)


開発現場の天国と地獄 について

第3回 ベテランならホントに安心なのか?

この記事はすごく面白い。逐一、自分の経験からも、納得させられる。
古い汎用機上がりの人はすごい設計をする。
経験20年のベテランといっても、どの言語をやってきたかというのが重要だ。
汎用機上がりの人に、オープン系は任せられない。短期開発にはついていけないのは目に見えている。頭も固い。ちょっと言い過ぎか。
ただ、最近の汎用機はRDBもきちんと設計し、またObjective COBOLなんていうのもの出てきているから、最近になって経験した人はいいが、昔の人はねえ。

それから、納品日になって、何もできていないことが発覚する。バクだらけ。これもよくある話だ。

通常プロジェクトの効率化の最大の障壁はコミュニケーションにあります。顧客の欲しいものをどう仕様策定者に伝えるか、仕様策定者はどう実装者に伝えるか、実装者は実装で起こった問題をどう仕様策定者や顧客にフィードバックするか。これらの間のロスは「打ち合わせ」や「文書の作成コスト」という形で表れます。

これも全くそのとおり。人を増やせばいいってものではない。実はコミュニケーションのコストというのは非常に大きい。

ジャストシステム:「一太郎」中止命令、納得できない

ジャストシステム:「一太郎」中止命令、納得できない

これまたビックな判決だ。
大昔の糞特許で、破棄、製造中止とまで言うとは。
IT業界に疎い、形式しかわからない裁判官に、判定する資格はないと思うのだが。

私は、100%ジャストシステム支持だな。
しかし、特許というのは難しい問題だ。

ただ松下の評判がこれで悪くなる、間違いない。

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。