Michael Hunger wrote: > I would not remove the methods as this is more according to the law of > demeter.
I see your point, but it also seems like an unnecessary duplication of methods. Also, typically one would use injection through @Structure to get to them. It should only be in really rare cases that one would access the CBF or OBF through the UoW. > I'd also have the nestedUoW() method of UOW use the > module().uowFactory().nestedUoW() internally. Why have UoW.nestedUoW() at all? Why not only support that through UoWF? > This kind of paused readonly uow is then quite common in repositories? I think so, yes. > Perhaps we should support that directly in the queryBuilderFactory or a > decorator thereof ? No, because it is up to the usecase of the caller whether it makes sense or not. > Regarding the communication between nested UOWs. What should the default > behaviour be for completing nested uows. > > Why don't they just get paused if they are nested instead of completed and > then completed when the outer uow > completes? So that the state changes are on hold until the outer uow > completes. As the outer one is not able to > access the changed states anyway that should be no problem? That's not strictly true. A nested UoW may do work on entities in the owning UoW, in which case it is important for the nested UoW to merge the changes in it down to the owning UoW, so that the continued work on the owning UoW sees those changes. But it is probably important to distinguish between these two, i.e. doing changes to an Entity from an owning UoW and an Entity that only exists in the nested UoW. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
