Referencing SQL fragments in another mapper file.

[Iwao AVE!]

Hi,

When an include element references an sql fragment in another
mapper, we must add mappers in the right order; or
IllegalArgumentException (XML fragments parsed from previous mappers
does not contain value for...) is thrown.
On the other hand, when a collection element references a result map
in another mapper, the order of mappers doesn't seem to matter.

This order restriction of include elements is not only unintuitive
but also doesn't work well with mapper auto-detection stuff (e.g.
MapperScannerConfigurator in mybatis-spring).
I guess there is a reason for this implementation, but isn't it
possible to overcome?

Thanks,
Iwao

[Poitras Christian]

Hi,

I had the same though.
I would like to work on this problem, but I didn't get much time for this.

For pure XML config, it's quite easy to fix since we can simply parse the mappers twice.
For Java config it much more difficult. We would need to post-pone the validation of the existence of the fragment until it is actually needed. This has the disadvantage to throw exception only when a fragment is accessed but not found. Right now, the problem is detected during configuration.
I don't think it's much of a problem since most people will do some unit testing to check if all statements are usable.

If you can provide a patch for this, I'll be glad to apply it.

Christian

-----Message d'origine-----
De : mybati...@googlegroups.com [mailto:mybati...@googlegroups.com] De la part de Iwao AVE!
Envoyé : November-21-10 9:55 PM
À : mybati...@googlegroups.com
Objet : Referencing SQL fragments in another mapper file.

[Iwao AVE!]

Hi Christian,

Thank you for a positive reply.
I have just started digging around, so no patch or alike at this point.

# Actually, before posting the first mail, I found issue 133 and
thought you had implemented that already ;-)

Here's the ticket for tracking this.
http://code.google.com/p/mybatis/issues/detail?id=179

Regards,
Iwao

2010/11/22 Poitras Christian <Christia...@ircm.qc.ca>:

[Poitras Christian]

What I've done is only patching the process a little.
To be more precise, XML config allowed used of fragments from other files as long as the order of the mappers in the XML config was correct. In java config, inclusion of fragment from other mappers failed.
I've modified java config to allow inclusion of fragment from previously parsed mappers. So now XML and java config works the same way. In both cases order matters.
That is also why, I've modified MyBatis-Guice to force mappers to be parsed in the order they are added to the module. This might not have been done in MyBatis-Spring yet.

If you can change MyBatis to allow use of "non-parsed yet" fragments, it would be awesome!

Christian

-----Message d'origine-----
De : mybati...@googlegroups.com [mailto:mybati...@googlegroups.com] De la part de Iwao AVE!

Envoyé : November-22-10 10:30 AM
À : mybati...@googlegroups.com
Objet : Re: Referencing SQL fragments in another mapper file.

[Iwao AVE!]

Thanks for the explanation, Christian.
I think I will have some time this weekend.

Regards,
Iwao

2010/11/23 Poitras Christian <Christia...@ircm.qc.ca>:

[Nathan Maves]

I actually think I just ran into the with the mybatis guice plugin as well.  I was trying to use the auto loading of mappers.  With cache-ref and I think the order is humping me.

N

[Iwao AVE!]

Thanks for the info.
I have added it to my TODOs.

// Iwao

2010/11/23 Nathan Maves <nathan...@gmail.com>:

[Poitras Christian]

Hi Nathan,

 

The change is very recent so I’m sure it’s not in any release prior to RC4. Normally, in RC4 the mappers should added in the config in the right order.

 

Christian

 

De : mybati...@googlegroups.com [mailto:mybati...@googlegroups.com] De la part de Nathan Maves
Envoyé : November-22-10 6:20 PM

[Iwao AVE!]

Christian,

I have uploaded the first version of the patch.
http://code.google.com/p/mybatis/issues/detail?id=179

--
Here's the summary of the changes I have made:

- When adding a mapper, all the statement nodes (i.e.
select,update,insert,delete) are stored into a temporary map without
being processed/parsed.

- There are basically two ways to parse the cached statement nodes:
1. By accessing Configuration.mappedStatement (e.g. via
getMappedStatement(String)). In this case, only the affected nodes are
processed (per namespace basis).
2. By calling Configuration#buildAllStatements(). With this method,
all the cached statement nodes are processed. It is recommended to
call this method once all the mappers are added as it provides
fail-fast statement validation.

# The patch includes a cache-ref related change which might be related
to the issue Nathan experienced.

Thanks in advance for your time,