leto
  •  
Options
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
日曜日 04 3
8:08 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-2.0.2
[maven-release-plugin] copy for tag dddbase-2.0.2
Options
  1. /dddbase/tags/dddbase-2.0.2
土曜日 03 3
12:08 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-2.0.1
[maven-release-plugin] copy for tag dddbase-2.0.1
Options
  1. /dddbase/tags/dddbase-2.0.1
12:03 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-2.0.0
[maven-release-plugin] copy for tag dddbase-2.0.0
Options
  1. /dddbase/tags/dddbase-2.0.0
10:07 am

都元ダイスケ

[maven-release-plugin] copy for tag jiemamy-master-2.0.0
[maven-release-plugin] copy for tag jiemamy-master-2.0.0
Options
  1. /jiemamy-master/tags/jiemamy-master-2.0.0
火曜日 17 1
10:03 pm

都元ダイスケ

[maven-release-plugin] copy for tag jiemamy-commons-0.1.7
[maven-release-plugin] copy for tag jiemamy-commons-0.1.7
Options
  1. /jiemamy-commons/tags/jiemamy-commons-0.1.7
10:03 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-1.4.1
[maven-release-plugin] copy for tag dddbase-1.4.1
Options
  1. /dddbase/tags/dddbase-1.4.1
9:45 pm

都元ダイスケ

[maven-release-plugin] copy for tag jiemamy-master-1.7.3
[maven-release-plugin] copy for tag jiemamy-master-1.7.3
Options
  1. /jiemamy-master/tags/jiemamy-master-1.7.3
土曜日 05 11 2011
3:08 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-1.4.0
[maven-release-plugin] copy for tag dddbase-1.4.0
Options
  1. /dddbase/tags/dddbase-1.4.0
  2. /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy/dddbase/utils
  3. /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy/dddbase
  4. /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy
  5. /dddbase/tags/dddbase-1.4.0/src/main/java/org
  6. /dddbase/tags/dddbase-1.4.0/src/main/java
  7. /dddbase/tags/dddbase-1.4.0/src/main
  8. /dddbase/tags/dddbase-1.4.0/src
    • -0
    • +193
    /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy/dddbase/utils/CloneUtil.java
    • -0
    • +55
    /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy/dddbase/spec/AndSpecification.java
  11. /dddbase/tags/dddbase-1.4.0/src/main/java/org/jiemamy/dddbase/spec
    • -0
    • +202
    /dddbase/tags/dddbase-1.4.0/LICENSE.txt
    • -0
    • +102
    /dddbase/tags/dddbase-1.4.0/src/test/java/org/jiemamy/dddbase/spec/SpecificationsTest.java
  14. /dddbase/tags/dddbase-1.4.0/src/test/java/org/jiemamy/dddbase/spec
  15. /dddbase/tags/dddbase-1.4.0/src/test/java/org/jiemamy/dddbase
  16. … 70 more files in changeset.
3:07 pm

都元ダイスケ

[maven-release-plugin] re-release
[maven-release-plugin] re-release
Options
  1. /dddbase/tags/dddbase-1.4.0
3:02 pm

都元ダイスケ

[maven-release-plugin] copy for tag dddbase-1.4.0
[maven-release-plugin] copy for tag dddbase-1.4.0
Options
  1. /dddbase/tags/dddbase-1.4.0
土曜日 05 2 2011
10:26 pm

都元ダイスケ

  • More
  • CR-32
  • summarized and closed
現状通りinsert or updateでいきます。

現状通りinsert or updateでいきます。

金曜日 04 2 2011
1:15 pm

都元ダイスケ

  • More
  • CR-30
  • summarized and closed
EntityNotFoundExceptionでいっときます。

EntityNotFoundExceptionでいっときます。

火曜日 18 1 2011
7:17 pm

都元ダイスケ

ユースケースドリブンで考えると、不要ですねー。ユースケースから出て来た問題ではないので。 単純に「ファイル実装だとopen時にアペンドモードがある」とか「RDBだとINSERTとUPDATEって分かれてるよなぁ」とか思った次第で。 しかしMapだとputで共通だなー、とか。 この場合、どっちがより適切なのかな、と思った感じです。"決めの問題" であれば、現状維持でも良いと思ってますー。

ユースケースドリブンで考えると、不要ですねー。ユースケースから出て来た問題ではないので。
単純に「ファイル実装だとopen時にアペンドモードがある」とか「RDBだとINSERTとUPDATEって分かれてるよなぁ」とか思った次第で。
しかしMapだとputで共通だなー、とか。

この場合、どっちがより適切なのかな、と思った感じです。"決めの問題" であれば、現状維持でも良いと思ってますー。

2:44 pm

Junichi Kato (j5ik2o)

Repositoryに親子関係があるなら、Chain of Responsibilityパターンで実装するという手もあるけど、今回の場合はCompositeRepositoryで十分かなと。

Repositoryに親子関係があるなら、Chain of Responsibilityパターンで実装するという手もあるけど、今回の場合はCompositeRepositoryで十分かなと。

10:19 am

Junichi Kato (j5ik2o)

insertとupdateという概念自体が実装の詳細というイメージがしているんですよね。全く主観です。insert(E entity), update(E entity)というシグニチャにすれば実害はないし、決めの問題だと思うんですが、個人的には今までstoreで事足りていたので、どういうユースケースがあるのかってところですね。自分はstore(insert or update)だけでよい派。

insertとupdateという概念自体が実装の詳細というイメージがしているんですよね。全く主観です。insert(E entity), update(E entity)というシグニチャにすれば実害はないし、決めの問題だと思うんですが、個人的には今までstoreで事足りていたので、どういうユースケースがあるのかってところですね。自分はstore(insert or update)だけでよい派。

9:33 am

都元ダイスケ

これって実装の詳細暴露に関わるネタだと思って無かったんですが、どの辺でしょう？ insert / update のタイミングで何かしたいので、実はイベントの仕組みは（まだ未成熟だけど）組み込んでます。 （ちなみに、これが domain event 俺、スレッドに弱いので、その辺はあらためて別件のレビュー立てます。が、同期化だけの責務を持ったリポジトリ、というのは同期化ラッパーのことですか？ ...

これって実装の詳細暴露に関わるネタだと思って無かったんですが、どの辺でしょう？
insert / update のタイミングで何かしたいので、実はイベントの仕組みは（まだ未成熟だけど）組み込んでます。
（ちなみに、これが domain event
俺、スレッドに弱いので、その辺はあらためて別件のレビュー立てます。が、同期化だけの責務を持ったリポジトリ、というのは同期化ラッパーのことですか？

とりあえず、Repositoryのインターフェイスとして、

  • "insert or update" は必要か、不要か、どっちでもいいのか
  • "insertだけ と updateだけ" は必要か、不要か、どっちでもいいのか


が論点ですが、どうでしょう？

8:37 am

都元ダイスケ

なんとなく決め手がないですねー。 まぁ、なんでこんなコトを思ったかって、「複数のリポジトリのいずれかに目的のエンティティがあって、横断検索する」ってケースがあったのです。その場合、 Entity entity = null; for(Repository repo : repos) { try { entity = repo.resolve(ref); break; ...

なんとなく決め手がないですねー。
まぁ、なんでこんなコトを思ったかって、「複数のリポジトリのいずれかに目的のエンティティがあって、横断検索する」ってケースがあったのです。その場合、 

Entity entity = null;
for(Repository repo : repos) {
  try {
    entity = repo.resolve(ref);
    break;
  } catch (ENFE e) {
    // ignore
  }
}

よりも、 

Entity entity = null;
Iterator<Repository> itr = repos.iterator();
while(entity == null && itr.hasNext()) {
    entity = itr.next().resolve(ref);
}


のが見通し良いかなぁ、とか考えたからです。まぁ、これは今は「CompositeRepository」を作ることによって解決していますが。そもそもどうあるべきなのかな、という疑問が残ったのでレビューに掛けた次第。

12:37 am

Junichi Kato (j5ik2o)

>エンティティ生成後、store前かもしれない。また、storeしたリポジトリが違うかもしれない。複数リポジトリが存在することもあるので。 ですね。 ＞では、EntityRefから引く場合（113行目）はどうでしょう？ こちらは「idが識別子を表す前提」以前に、実在するエンティティへの参照オブジェクトです。 EntityRefがエンティティへの参照と位置づけるなら、repositroy#r...

>エンティティ生成後、store前かもしれない。また、storeしたリポジトリが違うかもしれない。複数リポジトリが存在することもあるので。
ですね。

＞では、EntityRefから引く場合（113行目）はどうでしょう？ こちらは「idが識別子を表す前提」以前に、実在するエンティティへの参照オブジェクトです。
EntityRefがエンティティへの参照と位置づけるなら、repositroy#resolveでENFEは起きるべきでない。
しかし、EntityRefが存在している間に、与り知らぬところでrepository#remove(id)できてしまうと、repositroy#resolve(entityRef)でENFEになってしまうかも。

12:23 am

Junichi Kato (j5ik2o)

個人的には、実装の詳細に関わることは極力隠蔽したいかな。insertやupdateのタイミングで何かしないといけないなら、イベントを通知してもらう。 リポジトリはステートフルなんで、どの更新操作にも同期化は必要なんじゃないかな。同期化だけの責務を持ったリポジトリがあればいいかな。 スレッド単位でトランザクションを扱えるリポジトリはもっとめんどくさい気がする。

個人的には、実装の詳細に関わることは極力隠蔽したいかな。insertやupdateのタイミングで何かしないといけないなら、イベントを通知してもらう。
リポジトリはステートフルなんで、どの更新操作にも同期化は必要なんじゃないかな。同期化だけの責務を持ったリポジトリがあればいいかな。
スレッド単位でトランザクションを扱えるリポジトリはもっとめんどくさい気がする。

月曜日 17 1 2011
11:32 pm

Kazuki YAMAMOTO

  • More
  • CR-32
  • finished reviewing
11:31 pm

Kazuki YAMAMOTO

またJPAネタだけど。 今のstoreはJPAのmergeと一緒な気がするな。すれでにデータが有ればupdateになるし、なければinsertになる。JPAではあともう一つpersistってもあるけど、これが存在する理由はinsertのタイミングでユニーク制約を確認するためにあるはず(たぶん)。mergeだとupdateになっちゃうし。今回の地豆の場合だと、新規挿入時に明示的な制約を持ちた...

またJPAネタだけど。

今のstoreはJPAのmergeと一緒な気がするな。すれでにデータが有ればupdateになるし、なければinsertになる。JPAではあともう一つpersistってもあるけど、これが存在する理由はinsertのタイミングでユニーク制約を確認するためにあるはず(たぶん)。mergeだとupdateになっちゃうし。今回の地豆の場合だと、新規挿入時に明示的な制約を持ちたい場合はinsert用でもメソッド分けたほうがいいような気もする(UUIDだからユニークだし必要となること無いのかな？)。

マルチスレッドは良く解らんな。わけるわけないに関わらずスレッドセーフであるとは思うけど。

3:27 pm

都元ダイスケ

  • More
  • CR-32
  • started review
storeは「insert or update」か？
storeは「insert or update」か？
3:20 pm

都元ダイスケ

  • More
  • CR-31
  • started review
REPOSITORYのオンメモリ実装における「おもらし」チェック
REPOSITORYのオンメモリ実装における「おもらし」チェック
10:49 am

都元ダイスケ

解決に失敗＝IDが実在するエンティティを示さない ではないんですよね。 エンティティ生成後、store前かもしれない。また、storeしたリポジトリが違うかもしれない。複数リポジトリが存在することもあるので。 次に、上の話は置いといたとして。UUIDからEntityを引く場合の処理についてはひとまずOK。UUIDは単なる汎用識別子であって、それがEntityを識別する値であるとは限らないの...

解決に失敗＝IDが実在するエンティティを示さない ではないんですよね。
エンティティ生成後、store前かもしれない。また、storeしたリポジトリが違うかもしれない。複数リポジトリが存在することもあるので。

次に、上の話は置いといたとして。UUIDからEntityを引く場合の処理についてはひとまずOK。UUIDは単なる汎用識別子であって、それがEntityを識別する値であるとは限らないのには納得。
では、EntityRefから引く場合（113行目）はどうでしょう？ こちらは「idが識別子を表す前提」以前に、実在するエンティティへの参照オブジェクトです。

10:19 am

Kazuki YAMAMOTO

+1 関係ないかもしれんけどJPAのgetSingleResultもそんな感じの動作だな。

+1
関係ないかもしれんけどJPAのgetSingleResultもそんな感じの動作だな。

9:49 am

Keisuke.K

+1

+1

12:30 am

Junichi Kato (j5ik2o)

引数のidがエンティティの識別子を表す前提であれば、ENFE。ただし、ENFEをスローさせずにidが実在するエンティティを示しているか検査したい場合はcontains(id)で行う前提になると思う。 idが実在するエンティティを示さない場合を例外的状況と捉えるかどうか。やっぱり、idは間違うとデータ破損とかアプリケーションエラーを起こすので、間違ったidを指定したら例外が発生するほうが安全...

引数のidがエンティティの識別子を表す前提であれば、ENFE。ただし、ENFEをスローさせずにidが実在するエンティティを示しているか検査したい場合はcontains(id)で行う前提になると思う。

idが実在するエンティティを示さない場合を例外的状況と捉えるかどうか。やっぱり、idは間違うとデータ破損とかアプリケーションエラーを起こすので、間違ったidを指定したら例外が発生するほうが安全かな。。。nullがほしいような場合はcontainsで代替えできるとおもうので。

日曜日 16 1 2011
10:21 pm

都元ダイスケ

  • More
  • CR-30
  • started review
Repository#resolve系のメソッドで、解決に失敗した時の仕様
Repository#resolve系のメソッドで、解決に失敗した時の仕様
土曜日 25 12 2010
11:16 am

都元ダイスケ

  • More
  • CR-28
  • summarized and closed
due来たので終了。

due来たので終了。

10:24 am

都元ダイスケ

  • More
  • CR-29
  • summarized and closed
due過ぎたのでクローズ。

due過ぎたのでクローズ。

Earlier activity No later activity