Support for guava immutable collections

[GoogleCodeExporter]

What version of the MyBatis are you using?
r5445

Please describe the problem.  Unit tests are best!
Ability to use (some of) immutable collections 
(http://code.google.com/p/guava-libraries/) as return types in mappers. 
Basically it's just for the option to design api as immutable, i.e. to inform 
users that they should not need to modify the result.

Original issue reported on code.google.com by me...@rewor.cz on 26 Oct 2012 at 12:30

Attachments:

• mybatis_701.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the patch, but it would seem that it's better to have 
ImmutableCollectionObjectFactory implementing the ObjectFactory interface as 
that seems a more appropriate place to keep all of the object creation code, 
rather than changing classes like DefaultObjectFactory.
I'll try to take a look at it, but perhaps if you could think of reworking 
things so that the guava code is isolated to guava-specific classes such as 
ImmutableCollectionObjectFactory.

Original comment by gus4...@gmail.com on 28 Oct 2012 at 9:43

[GoogleCodeExporter]

I did try that. But it's really not fully-fledged object factory - it's a 
subset of what can create DefaultObjectFactory just like HashSets and 
ArrayLists. And (that's the catch) it can't work on its own - you need separate 
ObjectWrapper (Builder is not a Collection) and a way to convert the builder to 
the actual collection.

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

[GoogleCodeExporter]

Franta, have a look at this test

org.apache.ibatis.submitted.custom_collection_handling

It was the basis for enabling the support for scala collections (that are not 
java collections). 

May that work for you?

Original comment by eduardo.macarron on 30 Dec 2012 at 10:13

[GoogleCodeExporter]

I'm not sure I see your point. Do you suggest I should just use my own 
ObjectFactory & co.? If I want to do that, I wouldn't create this issue in the 
first place. With this approach 1) it won't work out of the box for all users 
2) I would need to copy DefaultObjectFactory and extend with this patch.

I'm afraid just replacing ObjectFactory is not enough. This patch needs a small 
yet important modification in MapperMethod - the object mybatis use as the 
collection isn't the collection itself, it's the builder. MapperMethod then 
turns the builder into the actual collection.

Original comment by me...@rewor.cz on 31 Dec 2012 at 10:20

[GoogleCodeExporter]

Sorry Franta. I just cross-read the patch and supposed something was wrong so 
you could not add the guava support.

The problem I see with the patch is that it requires guava (evident :) ) and 
one of the project objectives is keeping it clear of dependencies.

So I think the way to go to provide guava support is buiding a new pair of 
Factory + Wrapper and providing it as a separate add-in.

Original comment by eduardo.macarron on 1 Jan 2013 at 10:38

[GoogleCodeExporter]

The patch add support to use guava collections as return types if they are 
already on classpath. 

The guava-libs dependency is marked as optional, i.e. it won't be required, but 
is supported. It's needed only to compile mybatis, not run.

Original comment by me...@rewor.cz on 1 Jan 2013 at 11:03

[nmaruthi]

Hi @emacarron , others

I want to use Guava collections as return types in MyBatis. Can you please point me in the right direction for the same? Is it supported out of the box in myBatis ?

I want to use guava MultiMap and Table specifiaclly as return types.

Regards!