search

wangscript / warp-persist

Automatically exported from code.google.com/p/warp-persist
0 stars 0 forks source link

Annotation-bound modules support for @Transactional #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 

 Much like we have in the trunk for DF now: @UserAnnotation @Transactional.

Original issue reported on code.google.com by robbie.v...@gmail.com on 20 Aug 2008 at 11:52

GoogleCodeExporter commented 9 years ago 
@Transactional(unit=UserAnnotation.class) currently in trunk.

Original comment by robbie.v...@gmail.com on 23 Aug 2008 at 12:04

GoogleCodeExporter commented 9 years ago 
We should probably make our custom matchers public.

Original comment by robbie.v...@gmail.com on 8 Sep 2008 at 4:52

GoogleCodeExporter commented 9 years ago 
Yea good call. Let's put it in c.w.w.p.Matchers

Original comment by dha...@gmail.com on 9 Sep 2008 at 12:03

GoogleCodeExporter commented 9 years ago 
Done.

Original comment by robbie.v...@gmail.com on 9 Sep 2008 at 9:47

GoogleCodeExporter commented 9 years ago 
By the way, this has changed to PersistenceMatchers because of the naming 
conflict
with Guice.

Original comment by robbie.v...@gmail.com on 22 Dec 2008 at 2:28

GoogleCodeExporter commented 9 years ago 
Hmm, we dont really need unit= for the SPR case. I wonder if it would be easy 
to put that foot forward and fall 
back to the single nameless module for UOW.TRANSACTION?

Original comment by dha...@gmail.com on 23 Dec 2008 at 5:39

GoogleCodeExporter commented 9 years ago 
Can you explain? You mean we could do filtering in the transaction interceptor 
based 
on a ThreadLocal or something? In any case, regular modules are still 
supported. The 
downside is that we can't easily check that people aren't screwing up. For 
example if 
they create one annotated module and one regular module the regular module's 
interceptor will also intercept the annotated module's @Transactionals. 
Interesting, 
maybe we can actually detect that in the interceptor.

The default forAll configuration just matches on @Transactional and not on the 
unit; 
this allows for easier migration from annotated to 1.0-style, but we could also 
solve 
the above problem by always checking on the unit (there is a default unit). But 
then 
we should put a huge warning sign on forAll, because the defaults will use 
nonstandard matchers.

Thoughts?

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 11:38

GoogleCodeExporter commented 9 years ago 
I think we should do it, match on DefaultUnit by default. Then the docs must 
state 
that there is an implicit DefaultUnit, which is not visible in the bindings but 
is 
used for interception. So @Transactional will mean 
@Transaction(unit=DefaultUnit.class) (this is currently already true because we 
needed a default).

Original comment by robbie.v...@gmail.com on 23 Dec 2008 at 11:50