外だしSQLに要望
awaawa
awaawaです。
外だしSQLに要望です。
1.additionalForeignKeyMapで使える埋め込み区分値を外だしSQLでも使えるようにしてほしいです。
http://dbflute.sandbox.seasar.org/ja/manual/reference/dfprop/additionalforeignkey/index.html
※現状サポートしている区分値条件のオプションとは別で、あくまで区分値のある値を固定で記述したいです。
2.外だしSQLの結果をList<Map<String, String>>のような形で受け取れるようにしてほしいです。
CSV作成(ダウンロード)などでの利用を想定しています。
・CSVのヘッダ部分を外だしSQLの別名(AS)で賄いたい。
(ヘッダ部分(別名)が日本語の場合があり、CustomizeEntityを作るのは抵抗がある。)
・CSVの場合、外だしSQLのselect句に記述した順番で出力することが多いため、java側のコーディング量を減らしたい。
(DBMetaを使えば、ある程度は可能だと思いますが。)
3.外だしSQLをファイル指定だけでなく、SQL自体(SQL文字列)を指定できるようにしてほしいです。
これについても、CSV作成(ダウンロード)などでの利用を想定しています。
データベースに外だしSQLの内容を登録しておいて、その内容を実行したいです。
※SQLへ渡すパラメータ(ParameterBean)の内容は固定である前提で。
2、3はdbfluteのポリシーであるタイプセーフに反するとは思うのですが。。。
ご検討よろしくお願いします。
#
# なお、1.ですが、逆のパターンで、
# additionalForeignKeyMapのバインド変数コメントで
# CDefのパッケージ解決をすることができるでしょうか。
# 自分で確認すればいいことですが。。。
#
kubo
awaawaさん、こんにちは
> 1.additionalForeignKeyMapで使える埋め込み区分値を外だしSQLでも使えるようにしてほしいです。
> http://dbflute.sandbox.seasar.org/ja/manual/reference/dfprop/additionalforeignkey/index.html
> ※現状サポートしている区分値条件のオプションとは別で、あくまで区分値のある値を固定で記述したいです。
ParameterBeanの区分値オプションの拡張で対応しました。
// ParameterBean - 区分値条件のオプション
http://dbflute.sandbox.seasar.org/ja/manual/function/generator/task/sql2entity/parameterbean.html#classification
> 2.外だしSQLの結果をList<Map<String, String>>のような形で受け取れるようにしてほしいです。
> 3.外だしSQLをファイル指定だけでなく、SQL自体(SQL文字列)を指定できるようにしてほしいです。
残念ですが、これはDBFluteとしてはサポートしないので、
アプリ側の共通モジュールでかぶせて処理するようにしてください。
2 はDBMeta、3は埋め込み変数コメントってところですね。
> # なお、1.ですが、逆のパターンで、
> # additionalForeignKeyMapのバインド変数コメントで
> # CDefのパッケージ解決をすることができるでしょうか。
> # 自分で確認すればいいことですが。。。
少なくとも固定のバインド変数値にすることはできないですが、
$$CDef$$自体を利用することはできたようなできなかったような...
2011/9/11 awaawa <p1us3i...@gmail.com>:
> --
> このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
> このグループに投稿するには、dbf...@googlegroups.com にメールを送信してください。
> このグループから退会するには、dbflute+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/dbflute?hl=ja からこのグループにアクセスしてください。
>
>
awaawa
kubo
> ドキュメント確認中に、今回の件とは別件ですが、ドキュメントで間違えを見つけました。
ありがとう。別件じゃないね...w みごとに今回の件の部分だ...
直しました。
>> $$CDef$$自体を利用することはできたようなできなかったような...
> なるほど、exampleをいじって確認してみます。
> fixedConditionでDateクラスを指定するように、CDefクラスを指定できるとありがたいので。
やったらできた。(できるようにしてたはずだし)
dbflute-mysql-example で試しました。
awaawa
今回の件の部分でしたかー
それを踏まえて、再度確認したら、
「固定の区分値」の上にある「リスト型の区分値」も同様のようです。(おそらく参考元かと。)
五月雨で申し訳ないですが、ご確認よろしくお願いします。
> やったらできた。(できるようにしてたはずだし)
確認ありがとうございます。
できれば、ドキュメント上fixedConditionのCDefの例もあるとうれしいです。
(使う機会が多いと思うので。)
あとまえから疑問だったのですが、
additionalForeignKeyMapのページの最後にあるExampleの
「e.g. 会員から会員住所情報への有効期間条件付きのFK」
ですが、localTableNameとforeignTableNameって逆じゃないでしょうか。
自分のfixedConditionの捉え方が間違っているかもしれませんが。。。
On 9月11日, 午後7:20, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> > ドキュメント確認中に、今回の件とは別件ですが、ドキュメントで間違えを見つけました。
>
> ありがとう。別件じゃないね...w みごとに今回の件の部分だ...
> 直しました。
>
> >> $$CDef$$自体を利用することはできたようなできなかったような...
> > なるほど、exampleをいじって確認してみます。
> > fixedConditionでDateクラスを指定するように、CDefクラスを指定できるとありがたいので。
>
> やったらできた。(できるようにしてたはずだし)
> dbflute-mysql-example で試しました。
>
>
>
>
>
>
>
> > jfluteさん
> > awaawaです。
> >> 1.ParameterBeanの区分値オプションの拡張
> > 対応ありがとうございます。
> > ドキュメント確認中に、今回の件とは別件ですが、ドキュメントで間違えを見つけました。
> > ご確認をお願いします。
> > 「固定の区分値」でInScopeのSQLの例で「in」のはずが「=」になっています。
> > 了解です。共通モジュールで処理するように考えます。
> >> 少なくとも固定のバインド変数値にすることはできないですが、
> >> $$CDef$$自体を利用することはできたようなできなかったような...
> > なるほど、exampleをいじって確認してみます。
> > fixedConditionでDateクラスを指定するように、CDefクラスを指定できるとありがたいので。
>
> >> jfluteです。
>
> >> awaawaさん、こんにちは
>
> >> > 1.additionalForeignKeyMapで使える埋め込み区分値を外だしSQLでも使えるようにしてほしいです。
>
> >> > > http://dbflute.sandbox.seasar.org/ja/manual/reference/dfprop/addition...
>
> >> ParameterBeanの区分値オプションの拡張で対応しました。
>
> >> // ParameterBean - 区分値条件のオプション
>
> >> > 2.外だしSQLの結果をList<Map<String, String>>のような形で受け取れるようにしてほしいです。
> >> > 3.外だしSQLをファイル指定だけでなく、SQL自体(SQL文字列)を指定できるようにしてほしいです。
>
> >> 残念ですが、これはDBFluteとしてはサポートしないので、
> >> アプリ側の共通モジュールでかぶせて処理するようにしてください。
> >> 2 はDBMeta、3は埋め込み変数コメントってところですね。
>
> >> > # なお、1.ですが、逆のパターンで、
> >> > # additionalForeignKeyMapのバインド変数コメントで
> >> > # CDefのパッケージ解決をすることができるでしょうか。
> >> > # 自分で確認すればいいことですが。。。
>
> >> 少なくとも固定のバインド変数値にすることはできないですが、
> >> $$CDef$$自体を利用することはできたようなできなかったような...
>
> >> > jfluteさん
>
> >> > awaawaです。
>
> >> > 外だしSQLに要望です。
>
> >> > 1.additionalForeignKeyMapで使える埋め込み区分値を外だしSQLでも使えるようにしてほしいです。
>
> >> > > http://dbflute.sandbox.seasar.org/ja/manual/reference/dfprop/addition...
kubo
> それを踏まえて、再度確認したら、
> 「固定の区分値」の上にある「リスト型の区分値」も同様のようです。(おそらく参考元かと。)
ありがとう！ドキュメントの間違いは
なかなか見つけられないので助かります。
> できれば、ドキュメント上fixedConditionのCDefの例もあるとうれしいです。
> (使う機会が多いと思うので。)
入れました。
http://dbflute.sandbox.seasar.org/ja/manual/reference/dfprop/additionalforeignkey/index.html#fixedcondition
あらためて読むと
「パッケージ名の解決は、ParameterBeanにおけるプログラム型のパッケージ解決と同じです。」
ってことだったね。
> あとまえから疑問だったのですが、
> additionalForeignKeyMapのページの最後にあるExampleの
> 「e.g. 会員から会員住所情報への有効期間条件付きのFK」
> ですが、localTableNameとforeignTableNameって逆じゃないでしょうか。
> 自分のfixedConditionの捉え方が間違っているかもしれませんが。。。
ん！？これは合ってるよ。
localTableNameが会員、foreignTableNameで会員住所情報でいいよね？
有効期間条件を入れることで、会員から会員住所情報を
one-to-oneとして参照できるってことなので。
(無論、実際のFK制約は会員住所情報から会員だけど)
2011/9/11 awaawa <p1us3i...@gmail.com>:
awaawa
ドキュメント修正、両方とも確認できました。ありがとうございます。
> 「パッケージ名の解決は、ParameterBeanにおけるプログラム型のパッケージ解決と同じです。」
確かにそうですね!
> 有効期間条件を入れることで、会員から会員住所情報を
> one-to-oneとして参照できるってことなので。
なるほど。自分のfixedConditionの捉え方が間違っている感じですかね。
業務的one-to-oneは
one-to-manyの関係にmany側に条件を入れることで、
one-to-oneにしているので、
実際のFK制約と「FK制約を設定するテーブル」、「FKの参照先テーブル」は
変わらないと思っていました。
若干語弊がある解釈になるかもしれませんが、
業務的one-to-oneの場合、実際のFK制約とテーブルの関係は逆になるという考えでいいでしょうか。
On 9月11日, 午後8:44, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> > それを踏まえて、再度確認したら、
> > 「固定の区分値」の上にある「リスト型の区分値」も同様のようです。(おそらく参考元かと。)
>
> ありがとう！ドキュメントの間違いは
> なかなか見つけられないので助かります。
>
> > できれば、ドキュメント上fixedConditionのCDefの例もあるとうれしいです。
> > (使う機会が多いと思うので。)
>
> 「パッケージ名の解決は、ParameterBeanにおけるプログラム型のパッケージ解決と同じです。」
> ってことだったね。
>
> > あとまえから疑問だったのですが、
> > additionalForeignKeyMapのページの最後にあるExampleの
> > 「e.g. 会員から会員住所情報への有効期間条件付きのFK」
> > ですが、localTableNameとforeignTableNameって逆じゃないでしょうか。
> > 自分のfixedConditionの捉え方が間違っているかもしれませんが。。。
>
> ん！？これは合ってるよ。
> localTableNameが会員、foreignTableNameで会員住所情報でいいよね？
> 有効期間条件を入れることで、会員から会員住所情報を
> one-to-oneとして参照できるってことなので。
> (無論、実際のFK制約は会員住所情報から会員だけど)
>
>
> もっと読む ≫
kubo
> 実際のFK制約と「FK制約を設定するテーブル」、「FKの参照先テーブル」は
> 変わらないと思っていました。
> 若干語弊がある解釈になるかもしれませんが、
> 業務的one-to-oneの場合、実際のFK制約とテーブルの関係は逆になるという考えでいいでしょうか。
結局は考え方次第で、どっちがローカルにもなるんだけど、
業務的one-to-oneのリレーションと実際のFK制約のリレーションは
独立して捉えていて(少なくとも物理的な関連はない)、
many側に条件を入れることによってone側とoneの関係になる
論理的なテーブルが一時的に作成されて(ビューみたいな考え方)、
そのテーブルに対してone側が擬似的なFKとして参照する、
というような概念になっています。
普通のone-to-oneの逆方向のSetupSelectは、
固定条件が不要で自動解決できるので、
DBFluteがその擬似的なFKを自動付与してると言えます。
まあ、そんな小難しいことは考えずに、
「実際のFK制約とテーブルの関係は逆になる」でOK。
「とにかくSetupSelectする方向(local to foreign)」でもOK。
2011/9/11 awaawa <p1us3i...@gmail.com>:
awaawa
> まあ、そんな小難しいことは考えずに、
> 「実際のFK制約とテーブルの関係は逆になる」でOK。
> 「とにかくSetupSelectする方向(local to foreign)」でもOK。
On 9月11日, 午後10:03, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> > 実際のFK制約と「FK制約を設定するテーブル」、「FKの参照先テーブル」は
> > 変わらないと思っていました。
> > 若干語弊がある解釈になるかもしれませんが、
> > 業務的one-to-oneの場合、実際のFK制約とテーブルの関係は逆になるという考えでいいでしょうか。
>
> 結局は考え方次第で、どっちがローカルにもなるんだけど、
> 業務的one-to-oneのリレーションと実際のFK制約のリレーションは
> 独立して捉えていて(少なくとも物理的な関連はない)、
> many側に条件を入れることによってone側とoneの関係になる
> 論理的なテーブルが一時的に作成されて(ビューみたいな考え方)、
> そのテーブルに対してone側が擬似的なFKとして参照する、
> というような概念になっています。
>
> 普通のone-to-oneの逆方向のSetupSelectは、
> 固定条件が不要で自動解決できるので、
> DBFluteがその擬似的なFKを自動付与してると言えます。
>
> まあ、そんな小難しいことは考えずに、
> 「実際のFK制約とテーブルの関係は逆になる」でOK。
> 「とにかくSetupSelectする方向(local to foreign)」でもOK。
>
>
> もっと読む ≫
awaawa
awaawaです。
以下共通モジュールを作ろうと思っているのですが、再度教えていただいていいでしょうか。
>> 3.外だしSQLをファイル指定だけでなく、SQL自体(SQL文字列)を指定できるようにしてほしいです。
>残念ですが、これはDBFluteとしてはサポートしないので、
>アプリ側の共通モジュールでかぶせて処理するようにしてください。
>2 はDBMeta、3は埋め込み変数コメントってところですね。
外だしSQLのDBMeta.ColumnInfoにコメントを付ける方法はあるでしょうか。
ParameterBeanのプロパティのコメントのような感じで。
http://dbflute.sandbox.seasar.org/ja/manual/function/generator/task/sql2entity/parameterbean.html#parameterbeanmark
3.(2.も絡みますが。)
外だしSQLの埋め込み変数コメントでSelect句のカラムが可変な場合、
自動生成時はすべてのカラムがある状態で、自動生成する必要があると考えていいでしょうか。
・イメージ
/*IF pmb.dynamicClause == null*/
select カラム1, カラム2... from ...
/*END*/
/*IF pmb.dynamicClause != null*/
/*$pmb.dynamicClause*/
/*END*/
※このようなパターンは、dbfluteの自動生成以外の方法で(Entityの代わりの)バリューオブジェクトを作成したほうがいいでしょうか。
>
> もっと読む ≫
kubo
> 外だしSQLのDBMeta.ColumnInfoにコメントを付ける方法はあるでしょうか。
対応するカラムのDBコメントの説明ということかな？
それとも、その場で独自にコメントを付与ということかな？
前者は、CustomizeEntityのGetterに付与されます。
DBMetaは内部的なAPIという面とコンパイルスピードを考慮して、
JavaDocを付与していません。でも、そろそろ開発PCの性能も
ぐんとあがってきたから、あまり気にしなくもいいかなとも
考えています。(ちょっと検討中)
後者は、自動生成という特性上コメントを定義する箇所(タイミング)が
ないし、通常の CustomizeEntity であれば Getter をオーバーライドして、
JavaDocに好きなことを書いてしまえばOKですね。
> 外だしSQLの埋め込み変数コメントでSelect句のカラムが可変な場合、
> 自動生成時はすべてのカラムがある状態で、自動生成する必要があると考えていいでしょうか。
>
> ・イメージ
> /*IF pmb.dynamicClause == null*/
> select カラム1, カラム2... from ...
> /*END*/
> /*IF pmb.dynamicClause != null*/
> /*$pmb.dynamicClause*/
> /*END*/
なるほど、よく思い付いたね、これ。
> ※このようなパターンは、dbfluteの自動生成以外の方法で
> (Entityの代わりの)バリューオブジェクトを作成したほうがいいでしょうか。
これはその機能のアプリケーションにおける背景や
開発者の組織構造などに依存するので、現場にいない
自分からはなんとも言えないでしょう。
2011/9/28 awaawa <p1us3i...@gmail.com>:
awaawa
jfluteさん、おはようございます。
返信遅れてすいません。
〉その場で独自にコメントを付与
です。
ただ、javadocにつけたいのもありますが、
どちらかというと、
自動生成の際に、org.seasar.dbflute.dbmeta.info.ColumnInfoの_columnCommentにセットされ
て、
プログラムからカラムコメントを取得できたらと考えました。
外だしSQLを使って、WEBアプリでCSVダウンロード機能を実現するときに、
CSVのヘッダ部分も外だしSQL内で完結できるとうれしいので。
ColumnInfoの_propertyNameを取得して、
別途用意したプロパティファイルでCSVのヘッダ名を取得するのが本来あるべき姿かもしれませんが。
〉なるほど、よく思い付いたね、これ。
苦肉の策ですね…
DBのデータにSQL文自体を持っているのですが、
そのSQL文のSelect句のカラム内容は、多少増減があるものの基本同じだったので。
>
>
> > jfluteさん
>
> > awaawaです。
>
> > 以下共通モジュールを作ろうと思っているのですが、再度教えていただいていいでしょうか。
> >>> 2.外だしSQLの結果をList<Map<String, String>>のような形で受け取れるようにしてほしいです。
> >>> 3.外だしSQLをファイル指定だけでなく、SQL自体(SQL文字列)を指定できるようにしてほしいです。
> >>残念ですが、これはDBFluteとしてはサポートしないので、
> >>アプリ側の共通モジュールでかぶせて処理するようにしてください。
> >>2 はDBMeta、3は埋め込み変数コメントってところですね。
>
> > 2.
> > 外だしSQLのDBMeta.ColumnInfoにコメントを付ける方法はあるでしょうか。
> > ParameterBeanのプロパティのコメントのような感じで。
>
> もっと読む ≫
kubo
なるほど、独自のコメントか。
ちょっと考えたのは、
select FOO as FOO_ID -- // FOOです
, BAR as BAR_NAME -- // BARです
という形式で、「... as [識別カラム名] -- // [コメント]」という
形式でパースしてコメントにくっ付けるっていうはどうかなって。
別途「FOO_ID = FOOです」って定義するのは無しかなと。
どうせなら、普通に付けたいコメントがそのままコメントになれば。
でも、有用かどうか、もうちょっと思考を続けて検討しないとだな。
あと、ELSEコメント使っている場合に、
IFコメントからELSEコメントの間に行コメントが
利用できないって制限が今あるので、それをどうにしたいね...
2011/9/30 awaawa <p1us3i...@gmail.com>:
kubo
select FOO as FOO_ID -- // FOOです、asの次がカラム名
, foo.BAR_NAME -- // BARです、ドットの次がカラム名
, BAZ_NAME -- // BAZです、カンマの次がカラム名
という形式が書いておけば、これがそのカラムの
追加的なコメントになるようにしました。
DBリンクのプロシージャシノニムと同じくRC1です。
同時に、IFコメントとELSEコメントの間に普通の行コメント
を書けない制限を取っ払いました。
DBMetaのJavaDocコメントはとりあえず無しで。
やるなら他のメソッドも検討した方が良いし、
あくまでディベロッパーがあまり直接触るもの
ではないものなので。
2011/10/1 kubo <dbf...@gmail.com>:
awaawa
対応ありがとうございます。
まだ、動作確認途中ですが、確認、お願いをさせてください。
(dbflute-basic-exampleで確認しました。)
・追加コメントを使用する場合、「-- // 」の「 // 」は必須。またColumnInfo._commonColumnには改行+「 // 」
が含まれる。
→できれば、_commonColumnには改行+「 // 」が含まれないようにしてほしいです。
・DBからカラムのメタ情報が引けない場合は、この機能が適応されない(?)。
(「TEST > 0 AS TEST_FLG」などカラムの実体がない場合やRDB自体の制限でメタ情報が引けない場合)
→適応されるようにしてほしいです。
・DBから取得したメタ情報のカラムコメントに追加した形で_commonColumnに設定される。
→DBから取得したメタ情報のカラムコメントを上書きするオプションが欲しいです。
・「BAZ_NAME, -- // BAZです」 カンマの前がカラム名は追加コメントにならない。
→このパターンも適応することはできないでしょうか。(パースの関係上難しいでしょうか。)
On 10月1日, 午後7:32, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> select FOO as FOO_ID -- // FOOです、asの次がカラム名
> , foo.BAR_NAME -- // BARです、ドットの次がカラム名
> , BAZ_NAME -- // BAZです、カンマの次がカラム名
>
> という形式が書いておけば、これがそのカラムの
> 追加的なコメントになるようにしました。
> DBリンクのプロシージャシノニムと同じくRC1です。
>
> 同時に、IFコメントとELSEコメントの間に普通の行コメント
> を書けない制限を取っ払いました。
>
> DBMetaのJavaDocコメントはとりあえず無しで。
> やるなら他のメソッドも検討した方が良いし、
> あくまでディベロッパーがあまり直接触るもの
> ではないものなので。
>
>
>
>
>
>
>
> > jfluteです。
>
> > なるほど、独自のコメントか。
> > ちょっと考えたのは、
>
> > select FOO as FOO_ID -- // FOOです
> > , BAR as BAR_NAME -- // BARです
>
> > という形式で、「... as [識別カラム名] -- // [コメント]」という
> > 形式でパースしてコメントにくっ付けるっていうはどうかなって。
> > 別途「FOO_ID = FOOです」って定義するのは無しかなと。
> > どうせなら、普通に付けたいコメントがそのままコメントになれば。
> > でも、有用かどうか、もうちょっと思考を続けて検討しないとだな。
>
> > あと、ELSEコメント使っている場合に、
> > IFコメントからELSEコメントの間に行コメントが
> > 利用できないって制限が今あるので、それをどうにしたいね...
>
>
> もっと読む ≫
kubo
確認、フィードバックありがとう。
「TEST > 0 AS TEST_FLG」は修正しました。
「BAZ_NAME, -- // BAZです」もなんとかしました。
(個人的にはカンマ後ろいやなんだけどw)
> ・追加コメントを使用する場合、「-- // 」の「 // 」は必須。またColumnInfo._commonColumnには改行+「 // 」
> が含まれる。
> →できれば、_commonColumnには改行+「 // 」が含まれないようにしてほしいです。
あと、これはどちらかというと、アプリでパースしやすい
ようにって意味合いも含めて敢えて入れてるんだけどね。
「//」から改行までで切り取れば独自コメントになると。
(あとは独自コメントであることを見た目わかりやすく)
要は、メタ情報のカラムコメントの話と絡むわけだけど、
メタ情報のカラムコメントを抑制するオプションを付けるのは
簡単だけど、それはちょっとDBFluteの機能としては意味のある
機能とは思えないので、それはなしかなぁと。
そこまでやるならカラムコメントに入れ込むのではなく、
補足情報という形の別の保持領域を作る方がいいね。
CSVの共通モジュールの方で取り出せば良いと
思うのだけど、どうかな？
Srl.substringFirstFront(Srl.substringFirstRear(comment, "//"), "\n").trim();
2011/10/3 awaawa <p1us3i...@gmail.com>:
kubo
> 「TEST > 0 AS TEST_FLG」は修正しました。
> 「BAZ_NAME, -- // BAZです」もなんとかしました。
言い忘れていました、RC2で反映されています。
(ランタイムはRC1のままで)
2011/10/3 kubo <dbf...@gmail.com>:
awaawa
対応ありがとうございます。確認します。
> (個人的にはカンマ後ろいやなんだけどw)
カンマはやはり前にする方がいいんですかね。。。
前にした方が、内容の増減があったときに楽なのは分かっているのですが、
自分は、後にしてしまってますね。これを機に改めようか。。。
> そこまでやるならカラムコメントに入れ込むのではなく、
> 補足情報という形の別の保持領域を作る方がいいね。
確かにそうですね。
> Srl.substringFirstFront(Srl.substringFirstRear(comment, "//"), "\n").trim();
ちなみに、SrlはDBFlute的にアプリ側で使っても問題ないクラスですか。
それともあくまでDBFlute内部処理用のクラスの位置づけで、
アプリ側は、Apache Commons Langなどを使用した方がいいですか。
On 10月4日, 午前12:56, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> > 「TEST > 0 AS TEST_FLG」は修正しました。
> > 「BAZ_NAME, -- // BAZです」もなんとかしました。
>
> 言い忘れていました、RC2で反映されています。
> (ランタイムはRC1のままで)
>
>
>
>
>
>
>
> > jfluteです。
>
> > 確認、フィードバックありがとう。
> > 「TEST > 0 AS TEST_FLG」は修正しました。
> > 「BAZ_NAME, -- // BAZです」もなんとかしました。
> > (個人的にはカンマ後ろいやなんだけどw)
>
> >> ・追加コメントを使用する場合、「-- // 」の「 // 」は必須。またColumnInfo._commonColumnには改行+「 // 」
> >> が含まれる。
> >> →できれば、_commonColumnには改行+「 // 」が含まれないようにしてほしいです。
>
> > あと、これはどちらかというと、アプリでパースしやすい
> > ようにって意味合いも含めて敢えて入れてるんだけどね。
> > 「//」から改行までで切り取れば独自コメントになると。
> > (あとは独自コメントであることを見た目わかりやすく)
>
> > 要は、メタ情報のカラムコメントの話と絡むわけだけど、
> > メタ情報のカラムコメントを抑制するオプションを付けるのは
> > 簡単だけど、それはちょっとDBFluteの機能としては意味のある
> > 機能とは思えないので、それはなしかなぁと。
> > そこまでやるならカラムコメントに入れ込むのではなく、
> > 補足情報という形の別の保持領域を作る方がいいね。
>
> > CSVの共通モジュールの方で取り出せば良いと
> > 思うのだけど、どうかな？
> > Srl.substringFirstFront(Srl.substringFirstRear(comment, "//"), "\n").trim();
>
>
> もっと読む ≫
kubo
>> (個人的にはカンマ後ろいやなんだけどw)
> カンマはやはり前にする方がいいんですかね。。。
> 前にした方が、内容の増減があったときに楽なのは分かっているのですが、
> 自分は、後にしてしまってますね。これを機に改めようか。。。
い、いや、別にそこは無理には...
ツールとかのフォーマッタは後ろに来るのもあるし。
>> Srl.substringFirstFront(Srl.substringFirstRear(comment, "//"), "\n").trim();
> でやります。
> ちなみに、SrlはDBFlute的にアプリ側で使っても問題ないクラスですか。
使ってもいいけど、アプリの Util 経由で呼ぶ方がいいね。
内部クラスであることには変わりないので。
というか、自己責任の上で...ってOSSだからいずれにせよ
同じことだけど、ソースコードを丸コピーでもいいかも。
ちなみに、Srl は本当に内部利用を想定したもので、
外部で使うなら DfStringUtil という自然な名前で利用できます。
継承してるだけなんだけど、文字列操作って使う場合は
気軽に使いたいから、DBFlute は３文字クラスにしてるのだ。
2011/10/4 awaawa <p1us3i...@gmail.com>:
awaawa
カンマの位置は人のソース(SQL)をみると、どっちがいいんだろと思うんですよねー
> 使ってもいいけど、アプリの Util 経由で呼ぶ方がいいね。
了解です。
動作確認し次第、また連絡します。(おそらく今夜)
On 10月4日, 午前8:17, kubo <dbfl...@gmail.com> wrote:
> jfluteです。
>
> >> (個人的にはカンマ後ろいやなんだけどw)
> > カンマはやはり前にする方がいいんですかね。。。
> > 前にした方が、内容の増減があったときに楽なのは分かっているのですが、
> > 自分は、後にしてしまってますね。これを機に改めようか。。。
>
> い、いや、別にそこは無理には...
> ツールとかのフォーマッタは後ろに来るのもあるし。
>
> >> Srl.substringFirstFront(Srl.substringFirstRear(comment, "//"), "\n").trim();
> > でやります。
> > ちなみに、SrlはDBFlute的にアプリ側で使っても問題ないクラスですか。
>
> 使ってもいいけど、アプリの Util 経由で呼ぶ方がいいね。
> 内部クラスであることには変わりないので。
> というか、自己責任の上で...ってOSSだからいずれにせよ
> 同じことだけど、ソースコードを丸コピーでもいいかも。
> ちなみに、Srl は本当に内部利用を想定したもので、
> 外部で使うなら DfStringUtil という自然な名前で利用できます。
> 継承してるだけなんだけど、文字列操作って使う場合は
> 気軽に使いたいから、DBFlute は３文字クラスにしてるのだ。
>
>
> もっと読む ≫
awaawa
動作確認完了しました。
どちらも想定通り追加コメントになりました。
ありがとうございました。
> 「BAZ_NAME, -- // BAZです」もなんとかしました。
>
> もっと読む ≫