Support @Transactional on dynamic accessors

[GoogleCodeExporter]

We could detect @Transactional and support it without breaking compat.

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

[GoogleCodeExporter]

That's a pretty good idea. Unfortunately it doesn't work with custom matchers.

Is that a bad tradeoff?

Original comment by dha...@gmail.com on 21 Aug 2008 at 8:03

[GoogleCodeExporter]

If we add #8 it will not be an issue, but I understand the concern. The DF
functionality is getting complicated now I added the multiple modules support. 
I'll
document what we have on the wiki to improve our understanding of what the user 
is
going to have to deal with. We might need to give in some elegance for 
consistency.

Original comment by robbie.v...@gmail.com on 21 Aug 2008 at 8:43

[GoogleCodeExporter]

Original comment by robbie.v...@gmail.com on 21 Dec 2008 at 5:40

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

r255 has the initial implementation. 

We could actually filter incoming accessors through the TX matchers so we don't
transact finders when we don't have to (according to the tx config). I think 
that is
what people would expect so I'll have a look at that.

Original comment by robbie.v...@gmail.com on 21 Dec 2008 at 10:26

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by robbie.v...@gmail.com on 21 Dec 2008 at 10:26

• Changed state: Started

[GoogleCodeExporter]

r256 now respects the TX matchers. Not closing because we might want some more 
test
cases.

Original comment by robbie.v...@gmail.com on 21 Dec 2008 at 11:04

[GoogleCodeExporter]

Original comment by robbie.v...@gmail.com on 22 Dec 2008 at 10:40

• Changed state: Fixed

[GoogleCodeExporter]

Awesome!

Original comment by dha...@gmail.com on 23 Dec 2008 at 1:00