artemis

  •  
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[maven-release-plugin] copy for tag artemis-0.3.7
[maven-release-plugin] copy for tag artemis-0.3.7
[maven-release-plugin] copy for tag artemis-0.3.6
[maven-release-plugin] copy for tag artemis-0.3.6
[maven-release-plugin] copy for tag artemis-0.3.5
[maven-release-plugin] copy for tag artemis-0.3.5
[maven-release-plugin] copy for tag artemis-0.3.4
[maven-release-plugin] copy for tag artemis-0.3.4
[maven-release-plugin] copy for tag artemis-0.3.3
[maven-release-plugin] copy for tag artemis-0.3.3
[maven-release-plugin] copy for tag artemis-0.3.2
[maven-release-plugin] copy for tag artemis-0.3.2
    • -0
    • +35
    /tags/artemis-0.3.2/jiemamy-core/.project
    • -0
    • +174
    /tags/artemis-0.3.2/jiemamy-core/pom.xml
  1. … 518 more files in changeset.
[maven-release-plugin] rollback
[maven-release-plugin] rollback
    • -35
    • +0
    /tags/artemis-0.3.2/jiemamy-core/.project
    • -174
    • +0
    /tags/artemis-0.3.2/jiemamy-core/pom.xml
  1. … 518 more files in changeset.
[maven-release-plugin] copy for tag artemis-0.3.2
[maven-release-plugin] copy for tag artemis-0.3.2
    • -0
    • +35
    /tags/artemis-0.3.2/jiemamy-core/.project
    • -0
    • +174
    /tags/artemis-0.3.2/jiemamy-core/pom.xml
  1. … 518 more files in changeset.
[maven-release-plugin] rollback
[maven-release-plugin] rollback
[maven-release-plugin] copy for tag artemis-0.3.2
[maven-release-plugin] copy for tag artemis-0.3.2
  • More
  • CR-27
  • summarized and closed
DefaultCheckConstraintModel を作りたいから DefaultCheckConstraintModelBuilder を使うという関係なんですね。上記の回答内容で了解です。

DefaultCheckConstraintModel を作りたいから DefaultCheckConstraintModelBuilder を使うという関係なんですね。上記の回答内容で了解です。

  • More
  • CR-27
  • finished reviewing
to: yamkazu この内容でどうでしょ?

to: yamkazu
この内容でどうでしょ?

  • More
  • CR-27
  • finished reviewing
だいちゃんも言ってますが、DefaultCheckConstraintModel を作るのであれば DefaultCheckConstraintModelBuilder を作る時点で CheckConstraintModelBuilder 型で受け取る必要性が感じられないです。 あと実装の問題もあって、どの時点から Abstract Builder の VO 型を決定付けようか、という点。 ...

だいちゃんも言ってますが、DefaultCheckConstraintModel を作るのであれば DefaultCheckConstraintModelBuilder を作る時点で CheckConstraintModelBuilder 型で受け取る必要性が感じられないです。
あと実装の問題もあって、どの時点から Abstract Builder の VO 型を決定付けようか、という点。
現在の実装だと、例えば DefaultForeignKeyConstraintModelBuilder の階層は
ValueObjectBuilder -> ConstraintModelBuilder -> KeyConstraintModelBuilder -> ForeignKeyConstraintModelBuilder -> DefaultForeignKeyConstraintModelBuilder
になっていますが、DefaultPrimaryKeyConstraintModel の階層は
ValueObjectBuilder -> ConstraintModelBuilder -> KeyConstraintModelBuilder -> DefaultPrimaryKeyConstraintModelBuilder
となっています。
ここで、KeyConstraintModelBuilder の時点で VO 型を決定付けると、ForeignKeyConstraintModelBuilder#setXxx() の addConfigurator(new BuilderConfigurator<S>(){}) になっている部分の S が変えられようにも変えられないんですよ。
DefaultPrimaryKeyConstraintModelBuilder の前に PrimaryKeyConstraintModelBuilder を作れと言ってしまえばそれまでなんですが、実装が何もないクラスになります。
中身が空っぽのクラスがざっと増えるのはちょっと、と思ったので作らなかったんですが、どう思います?

なるほど。えびちゃん、解説願います。 個人的なイメージとしては、「DefaultCheckConstraintModelを作りたい」のだから、DefaultCheckConstraintModelBuilderを作る時点でCheckConstraintModelBuilder型で受け取る必要はあまりないかなぁ、なんて。

なるほど。えびちゃん、解説願います。

個人的なイメージとしては、「DefaultCheckConstraintModelを作りたい」のだから、DefaultCheckConstraintModelBuilderを作る時点でCheckConstraintModelBuilder型で受け取る必要はあまりないかなぁ、なんて。

  • More
  • CR-27
  • started review
[CORE-178]org.jiemamy.model.attribute.constraintのBuilderの継承関係について
[CORE-178]org.jiemamy.model.attribute.constraintのBuilderの継承関係について
  • More
  • CR-16
  • summarized and closed
  • More
  • CR-16
  • finished reviewing
エラーの方針であれば、可能ならばタイプセーフに、そもそも違った型を渡せないようにすべきかと思います。 タイプセーフ化が構造上不可能な時にのみ、やむを得ず IllegalArgumentException を選択すべきですね。

エラーの方針であれば、可能ならばタイプセーフに、そもそも違った型を渡せないようにすべきかと思います。
タイプセーフ化が構造上不可能な時にのみ、やむを得ず IllegalArgumentException を選択すべきですね。

  • More
  • CR-16
  • finished reviewing
たしかに便利だとおもうけどもDefaultForeignKeyConstraintModelBuilder#apply() であれば名前的にForeignKeyConstraintModel以外のものがわたって来たらIlleagalArgument扱いにした方がコードとしては混同しなくなっていいとも思う。

たしかに便利だとおもうけどもDefaultForeignKeyConstraintModelBuilder#apply() であれば名前的にForeignKeyConstraintModel以外のものがわたって来たらIlleagalArgument扱いにした方がコードとしては混同しなくなっていいとも思う。

アリだと思う?ナシだと思う?>all

アリだと思う?ナシだと思う?>all

完全未知のVOが渡ってきたら、build() と全く同じになるんすねー。 なるほど。悪くないと思ったけど…。この仕様アリかなー、ナシかなー。判断不能w

完全未知のVOが渡ってきたら、build() と全く同じになるんすねー。
なるほど。悪くないと思ったけど…。この仕様アリかなー、ナシかなー。判断不能w

CheckConstraintModel の階層上、DefaultFOreignKeyConstraintModelBuilder#apply() で受け付けられるのは ConstraintModel の内容までなので、name, logicalName, description がビルダにセットされますね。

CheckConstraintModel の階層上、DefaultFOreignKeyConstraintModelBuilder#apply() で受け付けられるのは ConstraintModel の内容までなので、name, logicalName, description がビルダにセットされますね。

これって、DefaultForeignKeyConstraintModelBuilder#apply() の引数にForeignKeyConstraintModel以外のVOをつっこんだらどうなりますか? 例えば CheckConstraintModel とか。

これって、DefaultForeignKeyConstraintModelBuilder#apply() の引数にForeignKeyConstraintModel以外のVOをつっこんだらどうなりますか? 例えば CheckConstraintModel とか。

  • More
  • CR-16
  • started review
[CORE-179] apply() の vo を T ではなく ValueObject に変更。それに伴う各ビルダの修正。
[CORE-179] apply() の vo を T ではなく ValueObject に変更。それに伴う各ビルダの修正。
  • More
  • CR-12
  • summarized and closed
ビルダーパターンか。ありかもしれないですね。試しに書いてみますね。

ビルダーパターンか。ありかもしれないですね。試しに書いてみますね。