ResultMap that uses association/collection columns if they exist, otherwise lazy loads

[Brian Pontarelli]

Quick question (to see if anyone knows before I test it). Can I write a ResultMap that will handle both lazy loading a collection, and using join columns if they exist in the ResultSet?

Here’s an example XML:

  <resultMap id="User" type="com.inversoft.cleanspeak.domain.system.User">
    <id property="id" column="u_id"/>
    <result property="email" column="u_email"/>
    <result property="password" column="u_password”/>

    <!— This should use the resultMap/nonNullColumn if the column exists in the ResultSet. Otherwise, it should use the lazy-select —>

    <collection property="roles" select=“SelectRoles” column=“u_id” resultMap="Role" notNullColumn="r_id"/>

  </resultMap>

-- Brian

[Eduardo Macarron]

Nope. It won't work. It will either fail (most likely) or consider only the join but not the select.

--
You received this message because you are subscribed to the Google Groups "mybatis-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mybatis-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Pontarelli]

Thanks. That saves me some time. 

The Inversoft team is putting together a list of couple of key features that we want to implement for MyBatis. Likely in the next couple months we will fork master and get them implemented and then do some pull requests. Our initial list is:

• Implement the lazy-load or join support for <association> and <collection>
• Implement ignore support for <association> and <collection> if the column doesn’t exist in the ResultSet
• Implement better prefix handling (helps with multi-table joins that include the same table twice)
• Implement an IN-CLAUSE spread operator for annotations
• Implement auto column listing and prefixing into @Select annotation for join selects

The first three will help us a lot because it will allow us to write a single ResultMap for every object and use it for both single table selects and join selects. The last two will likely help us use annotations for many complex queries without the mess of <script> and <foreach> tags.

-- Brian

[Eduardo Macarron]

All points look good Brian so thanks in advance for the future contribution. Count on us if you need any help.

[Iwao AVE!]

Hi Brian,

The third one sounds like the use case of columnPrefix.
You might want to see the test case mappers in the following directory.
http://git.io/uv_AlQ

Please just disregard this reply if you are already aware of the feature.

Thank you!
Iwao

[Brian Pontarelli]

My #3 is mostly around building the SELECT and not too much with the columnPrefix, because that part works pretty well already.

-- Brian

[Iwao AVE!]

Oh, I see.
Sorry about my misunderstanding and thank you for the explanation!

Regards,
Iwao