Slow SQL map verification for databases with large table count about mybatisnet HOT 5 OPEN

To verify what I mean by "on-the-fly verification," I'm simply suggesting that 
result maps aren't verified against their mapped classes until they are 
actually used. In any one session, a very small percentage of the actual tables 
in a database are interacted with and it seems like a waste of CPU cycles.

I'm suggesting this because we've recently implemented some WCF services that 
use iBatis, and MyBatis has to reinitialize and verify its maps every time a 
new connection to the service is established.

Maybe this problem shoul be a major priority. Applications that works with big 
databases "go on line" too slowly.

Just an update here. You can force verification of all of the maps by simply 
looping through them; we put this function in our Mapper class and call it once 
the mapper is init'd:

    Public Overridable Sub PreLoad()
        ' The trick is to load all of the statements for the mapper, which can
        ' be done by simply accessing their collection properties.
        Dim loadStatements As IEnumerator = Me.Mapper.MappedStatements.GetEnumerator()
        Dim loadParameterMaps As IEnumerator = Me.Mapper.ParameterMaps.GetEnumerator()
        Dim loadResultMaps As IEnumerator = Me.Mapper.ResultMaps.GetEnumerator()
    End Sub

This doesn't contribute much to the topic but is slightly related.

I agree, that this issue should be of higher priority. We have a long 
initialization time with a large number of sql maps too. All maps are loaded on 
startup and only a small number of them are really used. There should be a 
runtime mode which lazy loads and validates maps only when they are really 
executed.

I think the big issue with lazy-loading the maps when they are needed is that 
it might not be that trivial, all because you can reference maps and mappings 
from other SQL maps

Let's say you had <TableXYZMapper.xml>, and one of it's <resultMap>'s <result> 
attributes was <result ... resultMapping="TableABCMapper.SomeResultMapID" />.

Would MyBatis know at the time it needs to lazy-load TableXYZMapper that it 
also needs to load TableABCMapper? As it exists now, it loads everything all at 
once so it doesn't have to worry about these cross referenced setups.

This is the wall I hit when I described how "I've looked through the source 
code and it's a bit more complicated than I had hoped or I might have tried to 
do this myself" in my bug report.