•  
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[maven-release-plugin] copy for tag dddbase-2.0.2
[maven-release-plugin] copy for tag dddbase-2.0.2
[maven-release-plugin] copy for tag dddbase-2.0.1
[maven-release-plugin] copy for tag dddbase-2.0.1
[maven-release-plugin] copy for tag dddbase-2.0.0
[maven-release-plugin] copy for tag dddbase-2.0.0
[maven-release-plugin] copy for tag jiemamy-master-2.0.0
[maven-release-plugin] copy for tag jiemamy-master-2.0.0
  1. /jiemamy-master/tags/jiemamy-master-2.0.0
[maven-release-plugin] copy for tag jiemamy-commons-0.1.7
[maven-release-plugin] copy for tag jiemamy-commons-0.1.7
  1. /jiemamy-commons/tags/jiemamy-commons-0.1.7
[maven-release-plugin] copy for tag dddbase-1.4.1
[maven-release-plugin] copy for tag dddbase-1.4.1
[maven-release-plugin] copy for tag jiemamy-master-1.7.3
[maven-release-plugin] copy for tag jiemamy-master-1.7.3
  1. /jiemamy-master/tags/jiemamy-master-1.7.3
[maven-release-plugin] copy for tag dddbase-1.4.0
[maven-release-plugin] copy for tag dddbase-1.4.0
    • -0
    • +202
    /dddbase/tags/dddbase-1.4.0/LICENSE.txt
  1. … 70 more files in changeset.
[maven-release-plugin] re-release
[maven-release-plugin] re-release
[maven-release-plugin] copy for tag dddbase-1.4.0
[maven-release-plugin] copy for tag dddbase-1.4.0
  • More
  • CR-32
  • summarized and closed
現状通りinsert or updateでいきます。

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

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

EntityNotFoundExceptionでいっときます。

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

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

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

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

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

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)だけでよい派。

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

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

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

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


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

なんとなく決め手がないですねー。 まぁ、なんでこんなコトを思ったかって、「複数のリポジトリのいずれかに目的のエンティティがあって、横断検索する」ってケースがあったのです。その場合、 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」を作ることによって解決していますが。そもそもどうあるべきなのかな、という疑問が残ったのでレビューに掛けた次第。

>エンティティ生成後、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になってしまうかも。

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

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

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

またJPAネタだけど。

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

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

  • More
  • CR-32
  • started review
storeは「insert or update」か?
storeは「insert or update」か?
  • More
  • CR-31
  • started review
REPOSITORYのオンメモリ実装における「おもらし」チェック
REPOSITORYのオンメモリ実装における「おもらし」チェック
解決に失敗=IDが実在するエンティティを示さない ではないんですよね。 エンティティ生成後、store前かもしれない。また、storeしたリポジトリが違うかもしれない。複数リポジトリが存在することもあるので。 次に、上の話は置いといたとして。UUIDからEntityを引く場合の処理についてはひとまずOK。UUIDは単なる汎用識別子であって、それがEntityを識別する値であるとは限らないの...

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

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

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

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

+1

+1

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

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

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

  • More
  • CR-30
  • started review
Repository#resolve系のメソッドで、解決に失敗した時の仕様
Repository#resolve系のメソッドで、解決に失敗した時の仕様
  • More
  • CR-28
  • summarized and closed
due来たので終了。

due来たので終了。

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

due過ぎたのでクローズ。