Partial implementation of mapper in java

[GoogleCodeExporter]

What version of the MyBatis are you using?
trunk :)

Please describe the problem.  Unit tests are best!
Adds ability to provide implementation of some/all mapper methods. It's not 
ment as a replacement to existing xml mapping, but to allow things you can't 
(won't) do in sql; e.g. add some sort of logging/debugging code, split MERGE 
command to insert/update, provide a proxy when changing API, etc.

Original issue reported on code.google.com by me...@rewor.cz on 2 Aug 2012 at 12:25

Attachments:

• PartialMapperImpl.patch

[GoogleCodeExporter]

Hi. Thanks once again for your great contributions.

But, note that Javassist is still optional for 3.2 (unless we change our minds 
before the release)

Original comment by eduardo.macarron on 4 Aug 2012 at 12:19

[GoogleCodeExporter]

Ok, I can update the patch to handle the case that javassist is not available. 
Well, only if you think it is useful and it will be integrated :)

Original comment by me...@rewor.cz on 13 Aug 2012 at 8:20

[GoogleCodeExporter]

Issue 658 has been merged into this issue.

Original comment by eduardo.macarron on 27 Aug 2012 at 9:30

[GoogleCodeExporter]

Updated to r5406. Added cglib-based mapper proxy.

Original comment by me...@rewor.cz on 7 Sep 2012 at 10:10

Attachments:

• mybatis_645.patch

[GoogleCodeExporter]

Original comment by eduardo.macarron on 10 Sep 2012 at 5:14

• Added labels: Version-Release3.x, Component-SqlMaps

[GoogleCodeExporter]

Any update on this? I do actually quite need it :)

Original comment by me...@rewor.cz on 23 Oct 2012 at 4:18

[GoogleCodeExporter]

I am sorry but I am not completely sure that feature is a good idea. It adds 
indeed flexibility but blurrs the idea of "a mapper is just an interface".

Could you please open a discussion in the users group to see what others think 
about it?

Original comment by eduardo.macarron on 28 Oct 2012 at 9:11

[GoogleCodeExporter]

But the mapper is still an interface. This is an alternative to the 
_implementation_, just like annotations, sqlbuilders or xml files.

Original comment by me...@rewor.cz on 29 Oct 2012 at 10:52

[GoogleCodeExporter]

I have a need for this feature as well.

In fact, in addition to being able to use abstract classes as mappers, I also 
need the ability of mappers to be able to return (custom) collection types 
(e.g. Iterator and Iterable) in addition to the ones supported at the moment.

I understand that there is a reluctance to apply the patch proposed here, and I 
would also like to see it implemented differently. So may I propose as a first 
step that a custom MapperRegistry (needs to be converted to an interface) 
implementation can be registered with the Configuration? This way there would 
be clean hook to extend/re-implement the MapperRegistry if so desired.

Original comment by la...@posteo.de on 2 Dec 2012 at 7:47

[GoogleCodeExporter]

Lasse. You can return any object type that you want playing with the 
ObjectFactory and WrapperFactory. 

The ObjectFactory creates objects. You can provide your custom impl that 
creates the object you need when a mapper returns Iterable.

The ObjectWrapper is a wrap over any object. The scala project uses its own 
wrapper to handle scala native colections.

Original comment by eduardo.macarron on 3 Dec 2012 at 3:40

[GoogleCodeExporter]

Eduardo, 

thanks for the hint, I have solved the custom collection return values using my 
own Object(Wrapper)Factory implementations and it works fine!

I have two suggestions for small code changes that I needed to do but which are 
not specific to my concern:

(1) DefaultObjectFactory: add support for java.lang.Iterable by treating it 
exactly as if it where java.util.Collection
(2) SqlSessionFactoryBean: add setters for ojectFactory and 
objectWrapperFactory so they can be configured through Spring

This would enable me to remove some of my code and is helpful to other users as 
well.

Original comment by la...@posteo.de on 3 Dec 2012 at 9:22

[GoogleCodeExporter]

I've created issue 742 with a patch for the changes to SqlSessionFactoryBean 
I've suggested above.

Original comment by la...@posteo.de on 17 Dec 2012 at 5:54

[GoogleCodeExporter]

I have implemented support for mapper proxies using abstract classes by 
creating my an extension of MapperFactoryBean. This way, I only needed a tiny 
patch to the MyBatis to be able to subclass MapperProxy. 

I've attached that patch, it would be great if it could make it into the trunk.

Original comment by la...@posteo.de on 17 Dec 2012 at 6:47

Attachments:

• Issue_645.patch

[GoogleCodeExporter]

Cool, as a welcome side effect, change r5552 has made my suggested patch in 
comment #13 superflous.

Original comment by la...@posteo.de on 29 Dec 2012 at 9:48

[GoogleCodeExporter]

BTW I changed DefaultObjectFactory as suggested in r5563

Original comment by eduardo.macarron on 30 Dec 2012 at 8:18

[GoogleCodeExporter]

With the refactorings to the mapper proxy creation mechanism done as part of 
issue #734 it has now become quite easy to create mapper proxys that have a 
super class!

Here is the implementation I am using: https://gist.github.com/4574031

It provides a drop-in replacement for MyBatis-Spring's "MapperFactoryBean" 
allowing the configuration of MyBatis mapper proxys with an abstract super 
class that implements portions of the mapper interface. This implementation 
uses Javaassist to create proxys, but might be easily adapted to other proxy 
factories. Code based on MyBatis trunk rev. 5576 (to be released as 3.2.0) and 
MyBatis-Spring 1.1.0.

Original comment by la...@posteo.de on 19 Jan 2013 at 6:18