Sustitución de Strings

Por defecto, usar la sintaxis #{} hace que MyBatis genere propiedades de PreparedStatement y que asigne los valores a parámetros de PreparedStatement de forma segura (ej. ?). Aunque esto es más seguro, más rápido y casi siempre la opción adecuada, en algunos casos sólo quieres inyectar un trozo de texto sin modificaciones dentro de la sentencia SQL. Por ejemplo, para el caso de ORDER BY, podrías utilizar algo así:

ORDER BY ${columnName}

En este caso MyBatis no alterará el contenido del texto.

String Substitution can be very useful when the metadata(i.e. table name or column name) in the sql statement is dynamic, for example, if you want to select from a table by any one of its columns, instead of writing code like:

@Select("select * from user where id = #{id}")
User findById(@Param("id") long id);

@Select("select * from user where name = #{name}")
User findByName(@Param("name") String name);

@Select("select * from user where email = #{email}")
User findByEmail(@Param("email") String email);

// and more "findByXxx" method

@Select("select * from user where ${column} = #{value}")
User findByColumn(@Param("column") String column, @Param("value") String value);

User userOfId1 = userMapper.findByColumn("id", 1L);
User userOfNameKid = userMapper.findByColumn("name", "kid");
User userOfEmail = userMapper.findByColumn("email", "noone@nowhere.com");

This idea can be applied to substitute the table name as well.

NOTA No es seguro recoger un texto introducido por el usuario e inyectarlo en una sentencia SQL. Esto permite ataques de inyección de SQL y por tanto debes impedir que estos campos se informen con la entrada del usuario, o realizar tus propias comprobaciones o escapes.

Mapeo de resultados avanzado

MyBatis fue creado con una idea en mente: las bases de datos no siempre son como a ti te gustaría que fueran. Nos encantaría que todas las bases de datos estuvieran en 3ª forma normal o BCNF, pero no lo están. Sería genial que una base de datos encajara perfectamente con todas las aplicaciones que la usan pero no es así. Los ResultMaps son la respuesta de MyBatis a este problema.

Por ejemplo, ¿cómo mapearías este statement?

<!-- Very Complex Statement -->
<select id="selectBlogDetails" resultMap="detailedBlogResultMap">
  select
       B.id as blog_id,
       B.title as blog_title,
       B.author_id as blog_author_id,
       A.id as author_id,
       A.username as author_username,
       A.password as author_password,
       A.email as author_email,
       A.bio as author_bio,
       A.favourite_section as author_favourite_section,
       P.id as post_id,
       P.blog_id as post_blog_id,
       P.author_id as post_author_id,
       P.created_on as post_created_on,
       P.section as post_section,
       P.subject as post_subject,
       P.draft as draft,
       P.body as post_body,
       C.id as comment_id,
       C.post_id as comment_post_id,
       C.name as comment_name,
       C.comment as comment_text,
       T.id as tag_id,
       T.name as tag_name
  from Blog B
       left outer join Author A on B.author_id = A.id
       left outer join Post P on B.id = P.blog_id
       left outer join Comment C on P.id = C.post_id
       left outer join Post_Tag PT on PT.post_id = P.id
       left outer join Tag T on PT.tag_id = T.id
  where B.id = #{id}
</select>

Posiblemente te gustaría mapearlo a un modelo de objetos formado por un Blog que ha sido escrito por un Autor, y tiene varios Posts, cada uno de ellos puede tener cero o varios comentarios y tags. A continuación puede observarse un ResultMap complejo (asumimos que Author, Blog, Post, Comments y Tags son typeAliases). Échale un vistazo, pero no te preocupes, iremos paso a paso. Aunque parece enorme, es en realidad, bastante sencillo.

<!-- Very Complex Result Map -->
<resultMap id="detailedBlogResultMap" type="Blog">
  <constructor>
    <idArg column="blog_id" javaType="int"/>
  </constructor>
  <result property="title" column="blog_title"/>
  <association property="author" javaType="Author">
    <id property="id" column="author_id"/>
    <result property="username" column="author_username"/>
    <result property="password" column="author_password"/>
    <result property="email" column="author_email"/>
    <result property="bio" column="author_bio"/>
    <result property="favouriteSection" column="author_favourite_section"/>
  </association>
  <collection property="posts" ofType="Post">
    <id property="id" column="post_id"/>
    <result property="subject" column="post_subject"/>
    <association property="author" javaType="Author"/>
    <collection property="comments" ofType="Comment">
      <id property="id" column="comment_id"/>
    </collection>
    <collection property="tags" ofType="Tag" >
      <id property="id" column="tag_id"/>
    </collection>
    <discriminator javaType="int" column="draft">
      <case value="1" resultType="DraftPost"/>
    </discriminator>
  </collection>
</resultMap>

El elemento resultMap tiene varios sub-elementos y una estructura que merece la pena comentar. A continuación se muestra una vista conceptual del elemento resultMap.

resultMap

• constructor - usado para inyectar resultados en el constructor de la clase durante la instanciación
  • idArg - argumento ID; marcar el argumento ID mejora el rendimiento
  • arg - un resultado normal inyectado en el constructor
• id – result ID; marcar los results con ID mejora el rendimiento
• result – un resultado normal inyectado en un campo o una propiedad de un JavaBean
• association – una asociación con un objeto complejo; muchos resultados acabarán siendo de este tipo
  • result mapping anidado – las asociaciones son resultMaps en sí mismas o pueden apuntar a otro resultMap
• collection – una colección de tipos complejos
  • result mapping anidado – las colecciones son resultMaps en sí mismas o pueden apuntar a otro resultMap
• discriminator – utiliza un valor del resultado para determinar qué resultMap utilizar
  • case – un resultMap basado en un valor concreto
    • result mapping anidado – un case es un resultMap en sí mismo y por tanto puede contener a su vez elementos propios de un resultMap o bien apuntar a un resultMap externo.

Buena práctia Construye los ResultMaps de forma incremental. Las pruebas unitarias son de gran ayuda en ellos. Si intentas construir un ResultMap gigantesco como el que se ha visto anteriormente, es muy probable que lo hagas mal y será difícil trabajar con él. Comienza con una versión sencilla y evolucionarla paso a paso. Y haz pruebas unitarias! La parte negativa de utilizar frameworks es que a veces son una caja negra (sean opensource o no). Lo mejor que puedes hacer para asegurar que estás consiguiendo el comportamiento que pretendes es escribir pruebas unitarias. También son de utilidad para enviar bugs.

Las próximas secciones harán un recorrido por cada uno de los elementos en detalle.

id, result

<id property="id" column="post_id"/>
<result property="subject" column="post_subject"/>

Estos son los ResultMaps más sencillos. Ambos id, y result mapean una columna con una propiedad o campo de un tipo de dato simple (String, int, double, Date, etc.).

La única diferencia entre ambos es que id marca que dicho resultado es un identificador y dicha propiedad se utilizará en las comparaciones entre instancias de objetos. Esto mejora el rendimiento global y especialmente el rendimiento de la cache y los mapeos anidados (ej. mapeo de joins).

Cada uno tiene los siguientes atributos:

Tipos JDBC soportados

Para referencia futura, MyBatis soporta los siguientes tipos JDBC por medio de la enumeración JdbcType.

constructor

Aunque las propiedades funcionan bien en clases tipo Data Transfer Object (DTO), y posiblemente en la mayor parte de tu modelo de dominio, hay algunos casos en los que puedes querer clases inmutables. En ocasiones, las tablas que contienen información que nunca o raramente cambia son apropiadas para las clases inmutables. La inyección en el constructor te permite informar valores durante la instanciación de la clase, sin necesidad de exponer métodos públicos. MyBatis tambien soporta propiedades privadas para conseguir esto mismo pero habrá quien prefiera utilizar la inyección de Constructor. El elemento constructor permite hacer esto.

Dado el siguiente constructor:

public class User {
   //...
   public User(Integer id, String username, int age) {
     //...
  }
//...
}

In order to inject the results into the constructor, MyBatis needs to identify the constructor for somehow. In the following example, MyBatis searches a constructor declared with three parameters: java.lang.Integer, java.lang.String and int in this order.

<constructor>
   <idArg column="id" javaType="int"/>
   <arg column="username" javaType="String"/>
   <arg column="age" javaType="_int"/>
</constructor>

When you are dealing with a constructor with many parameters, maintaining the order of arg elements is error-prone.
Since 3.4.3, by specifying the name of each parameter, you can write arg elements in any order. To reference constructor parameters by their names, you can either add @Param annotation to them or compile the project with '-parameters' compiler option and enable useActualParamName (this option is enabled by default). The following example is valid for the same constructor even though the order of the second and the third parameters does not match with the declared order.

<constructor>
   <idArg column="id" javaType="int" name="id" />
   <arg column="age" javaType="_int" name="age" />
   <arg column="username" javaType="String" name="username" />
</constructor>

javaType can be omitted if there is a writable property with the same name and type.

El resto de atributos son los mismos que los de los elementos id y result.

association

<association property="author" javaType="Author">
  <id property="id" column="author_id"/>
  <result property="username" column="author_username"/>
</association>

El elemento association trata las relaciones de tipo “tiene-un”. Por ejemplo, en nuestro ejemplo, un Blog tiene un Autor. Un mapeo association funciona casi como cualquier otro result. Debes especificar la propiedad destino, el javaType de la propiedad (que normalmente MyBatis puede adivinar), el jdbcType si fuera necesario y un typeHandler si quieres sobre escribir el tratamiento de los valores de retorno.

Donde la association es distinta es en que debes indicar a MyBatis como cargar la asociación. MyBatis puede hacerlo de dos formas distintas:

• Nested Select: Ejecutando otra select que devuelve el tipo complejo deseado.
• Nested Results: Usando un ResultMap anidado que trata con los datos repetidos de resultsets provenientes de joins.

Primeramente, examinemos la propiedades del elemento. Como veras, es distinto de un ResultMap normal solo por los atributos select y resultMap.

Select anidada en Association

Por ejemplo:

<resultMap id="blogResult" type="Blog">
  <association property="author" column="author_id" javaType="Author" select="selectAuthor"/>
</resultMap>

<select id="selectBlog" resultMap="blogResult">
  SELECT * FROM BLOG WHERE ID = #{id}
</select>

<select id="selectAuthor" resultType="Author">
  SELECT * FROM AUTHOR WHERE ID = #{id}
</select>

Tenemos dos statements: uno para cargar el Blog, el otro para cargar el Autor, y el RestulMap de Blog describe que la sentencia “selectAuthor” debe utilizarse para cargar su propiedad author.

Todas las demás propiedades se cargarán automáticamente asumiendo que los nombres de propiedad y de columna coinciden.

Aunque este enfoque es simple, puede no tener un buen rendimiento con gran cantidad de datos. Este problema es conocido como “El problema de las N+1 Selects”. En resumidas cuentas, el problema de N+1 selects está causado por esto:

• Ejecutas una sentencia SQL para obtener una lista de registros (el “+1”).
• Para cada registro obtenido ejecutas una select para obtener sus detalles (el “N”).

Este problema puede provocar la ejecución de cientos o miles de sentencias SQL. Lo cual no es demasiado recomendable.

MyBatis puede cargar esas consultas de forma diferida (lazy load), por lo tanto se evita el coste de lanzar todas esas consultas a la vez. Sin embargo, si cargas la lista e inmediatamente iteras por ella para acceder a los datos anidados, acabarás cargando todos los registros y por lo tanto el rendimiento puede llegar a ser muy malo.

Así que, hay otra forma de hacerlo.

ResultMaps anidadas en Association

Previamente has visto un ejemplo muy complejo de asociaciones anidadas. Lo que se muestra a continuación es un ejemplo más simple que muestra cómo funciona esta característica. En lugar de ejecutar un statement separado, vamos a hacer una JOIN de las tablas Blog y Author de la siguiente forma:

<select id="selectBlog" resultMap="blogResult">
  select
    B.id            as blog_id,
    B.title         as blog_title,
    B.author_id     as blog_author_id,
    A.id            as author_id,
    A.username      as author_username,
    A.password      as author_password,
    A.email         as author_email,
    A.bio           as author_bio
  from Blog B left outer join Author A on B.author_id = A.id
  where B.id = #{id}
</select>

Fíjate en la join, y el especial cuidado que se ha dedicado a que todos los resultados tengan un alias que les de un nombre único y claro. Esto hace el mapeo mucho más sencillo. Ahora podemos mapear los resultados:

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <association property="author" javaType="Author" resultMap="authorResult"/>
</resultMap>

<resultMap id="authorResult" type="Author">
  <id property="id" column="author_id"/>
  <result property="username" column="author_username"/>
  <result property="password" column="author_password"/>
  <result property="email" column="author_email"/>
  <result property="bio" column="author_bio"/>
</resultMap>

En el ejemplo anterior puedes ver que la asociación “author” de Blog delega la carga de las instancias de Author en el ResultMap “authorResult”.

Muy importante: El elemento id tiene un papel muy importante en el mapeo de resultados anidados. Debes especificar siempre una o más propiedades que se puedan usar para identificar unívocamente los resultados. Lo cierto es que MyBatis también va a funcionar si no lo haces pero a costa de una importante penalización en rendimiento. Elige el número mínimo de propiedades que pueda identificar unívocamente un resultado. La clave primaria es una elección obvia (incluso si es compuesta).

En el ejemplo anterior se usa un resultMap externo para mapear la asociación. Esto hace que el resultMap del Autor sea reusable. Sin embargo, si no hay necesidad de reusarla o simplemente prefieres colocar todos los mapeos en un solo ResultMap, puedes anidarlo en la propia asociación. A continuación se muestra un ejemplo de este enfoque:

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <association property="author" javaType="Author">
    <id property="id" column="author_id"/>
    <result property="username" column="author_username"/>
    <result property="password" column="author_password"/>
    <result property="email" column="author_email"/>
    <result property="bio" column="author_bio"/>
  </association>
</resultMap>

Pero ¿y si el blog tiene un co-autor? La select sería algo así:

<select id="selectBlog" resultMap="blogResult">
  select
    B.id            as blog_id,
    B.title         as blog_title,
    A.id            as author_id,
    A.username      as author_username,
    A.password      as author_password,
    A.email         as author_email,
    A.bio           as author_bio,
    CA.id           as co_author_id,
    CA.username     as co_author_username,
    CA.password     as co_author_password,
    CA.email        as co_author_email,
    CA.bio          as co_author_bio
  from Blog B
  left outer join Author A on B.author_id = A.id
  left outer join Author CA on B.co_author_id = CA.id
  where B.id = #{id}
</select>

Recuerda que el resultMap de Author está definido de la siguiente forma.

<resultMap id="authorResult" type="Author">
  <id property="id" column="author_id"/>
  <result property="username" column="author_username"/>
  <result property="password" column="author_password"/>
  <result property="email" column="author_email"/>
  <result property="bio" column="author_bio"/>
</resultMap>

Dado que los nombres de columnas de los resultados difieren de los nombres especidficados en el resultMap, necesitas especificar un atributo columnPrefix para poder reusar el result map de Author para los co-autores.

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <association property="author"
    resultMap="authorResult" />
  <association property="coAuthor"
    resultMap="authorResult"
    columnPrefix="co_" />
</resultMap>

ResultSets múltiples en Association

Desce la versión 3.2.3 MyBatis proporciona otra forma más de resolver el problema del N+1.

Algunas bases de datos permiten que un procedimiento almacenado devuelva más de un resultset o ejecutar más de una sentencia a la vez y obtener de vuelta un resultset por cada. Esto se puede usar para acceder una sola vez a la base de datos y obtener datos relacionados sin usar una join.

En el ejemplo, el procedimiento almacenado deolverá dos result sets. El primero contendrá Blogs y el segundo Authors.

SELECT * FROM BLOG WHERE ID = #{id}

SELECT * FROM AUTHOR WHERE ID = #{id}

Se debe proporcionar un nombre a cada resultset informando el atributo resultSets del mapped statement con una lista de nombres separados por comas.

<select id="selectBlog" resultSets="blogs,authors" resultMap="blogResult" statementType="CALLABLE">
  {call getBlogsAndAuthors(#{id,jdbcType=INTEGER,mode=IN})}
</select>

Ahora podemos especificar que los datos para rellenar la asociación "author" vienen en el result set "authors":

<resultMap id="blogResult" type="Blog">
  <id property="id" column="id" />
  <result property="title" column="title"/>
  <association property="author" javaType="Author" resultSet="authors" column="author_id" foreignColumn="id">
    <id property="id" column="id"/>
    <result property="username" column="username"/>
    <result property="password" column="password"/>
    <result property="email" column="email"/>
    <result property="bio" column="bio"/>
  </association>
</resultMap>

Has visto como se utiliza la asociación “Tiene Un”. Pero ¿qué hay que el “Tiene Muchos”? Ese es el contenido de la siguiente sección.

collection

<collection property="posts" ofType="domain.blog.Post">
  <id property="id" column="post_id"/>
  <result property="subject" column="post_subject"/>
  <result property="body" column="post_body"/>
</collection>

El elemento collection funciona de forma casi idéntica al association. En realidad, es tan similar, que documentar todas las similitudes sería redundante. Así que enfoquémonos en las diferencias.

Para continuar con nuestro ejemplo anterior, un Blog solo tiene un Autor. Pero un Blog tiene muchos Posts. En la clase Blog esto se representaría con algo como:

private List<Post> posts;

Para mapear un conjunto de resultados anidados a una Lista como esta, debemos usar el elemento collection. Al igual que el elemento association, podemos usar una select anidada, o bien resultados anidados cargados desde una join.

Select anidada en Collection

Primeramente, echemos un vistazo al uso de una select anidada para cargar los Posts de un Blog.

<resultMap id="blogResult" type="Blog">
  <collection property="posts" javaType="ArrayList" column="id" ofType="Post" select="selectPostsForBlog"/>
</resultMap>

<select id="selectBlog" resultMap="blogResult">
  SELECT * FROM BLOG WHERE ID = #{id}
</select>

<select id="selectPostsForBlog" resultType="Post">
  SELECT * FROM POST WHERE BLOG_ID = #{id}
</select>

Hay unas cuantas diferencias que habrás visto de forma inmediata, pero la mayor parte tiene el mismo aspecto que el elemento association que vimos anteriormente. Primeramente, verás que estamos usando el elemento collection. Verás también que hay un nuevo atributo “ofType”. Este atributo es necesario para distinguir el tipo de la propiedad del JavaBean (o del campo) y el tipo contenido por la colección. Por tanto podrías leer el siguiente mapeo de esta forma:

<collection property="posts" javaType="ArrayList" column="id" ofType="Post" select="selectPostsForBlog"/>

Leído como: "Una colección de posts en un ArrayList de tipos Post."

El javaType es casi siempre innecesario, porque MyBatis lo adivinará en la mayoría de los casos. Así que podrías acortarlo de esta forma:

<collection property="posts" column="id" ofType="Post" select="selectPostsForBlog"/>

ResultMaps anidados en Collection

A estas alturas, posiblemente ya imaginarás cómo funcionan los ResultMaps anidados en una colección porque funcionan exactamente igual que en una asociación, salvo por que se añade igualmente el atributo “ofType”.

Primero, echemos un vistazo al SQL:

<select id="selectBlog" resultMap="blogResult">
  select
  B.id as blog_id,
  B.title as blog_title,
  B.author_id as blog_author_id,
  P.id as post_id,
  P.subject as post_subject,
  P.body as post_body,
  from Blog B
  left outer join Post P on B.id = P.blog_id
  where B.id = #{id}
</select>

Nuevamente hemos hecho una JOIN de las tablas Blog y Post, y hemos tenido cuidado de asegurarnos que las columnas obtenidas tienen un alias adecuado. Ahora, mapear un Blog y colección de Post es tan simple como:

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <collection property="posts" ofType="Post">
    <id property="id" column="post_id"/>
    <result property="subject" column="post_subject"/>
    <result property="body" column="post_body"/>
  </collection>
</resultMap>

Nuevamente, recuerda la importancia del elemento id, o lee la sección de asociación si no lo has hecho aun.

Además, si prefieres el formato más largo que aporta más reusabilidad a tus ResultMaps, puedes utilizar esta forma alternativa de mapeo:

<resultMap id="blogResult" type="Blog">
  <id property="id" column="blog_id" />
  <result property="title" column="blog_title"/>
  <collection property="posts" ofType="Post" resultMap="blogPostResult" columnPrefix="post_"/>
</resultMap>

<resultMap id="blogPostResult" type="Post">
  <id property="id" column="id"/>
  <result property="subject" column="subject"/>
  <result property="body" column="body"/>
</resultMap>

ResultSets múltiples en Collection

De la misma forma que hicimos en la association, podemos llamar a un procedimiento almacenado que devuelva dos resultsets, uno con Blogs y otro con Posts:

SELECT * FROM BLOG WHERE ID = #{id}

SELECT * FROM POST WHERE BLOG_ID = #{id}

Se debe proporcionar un nombre a cada resultset informando el atributo resultSets del mapped statement con una lista de nombres separados por comas.

<select id="selectBlog" resultSets="blogs,posts" resultMap="blogResult">
  {call getBlogsAndPosts(#{id,jdbcType=INTEGER,mode=IN})}
</select>

Especificamos que la collection "posts" se rellenará con datos contenidos en el resultset llamado "posts":

<resultMap id="blogResult" type="Blog">
  <id property="id" column="id" />
  <result property="title" column="title"/>
  <collection property="posts" ofType="Post" resultSet="posts" column="id" foreignColumn="blog_id">
    <id property="id" column="id"/>
    <result property="subject" column="subject"/>
    <result property="body" column="body"/>
  </collection>
</resultMap>

NOTA No hay límite en profundidad, amplitud o combinaciones de las asociaciones y colecciones que mapees. Debes tener en cuenta el rendimiento cuando crees los mapeos. Las pruebas unitarias y de rendimiento de tu aplicación son de gran utilidad para conocer cuales el mejor enfoque para tu aplicación. La parte positiva es que MyBatis te permite cambiar de opinión más tarde, con muy poco (o ningún) cambio en tu código.

El mapeo de asociaciones y colecciones es un tema denso. La documentación solo puede llevarte hasta aquí. Con un poco de práctica, todo se irá aclarando rápidamente.

discriminator

<discriminator javaType="int" column="draft">
  <case value="1" resultType="DraftPost"/>
</discriminator>

En ocasiones una base de datos puede devolver resultados de muchos y distintos (y esperamos que relacionados) tipos de datos. El elemento discriminator fue diseñado para tratar esta situación, y otras como la jerarquías de herencia de clases. El discriminador es bastante fácil de comprender, dado que funciona muy parecido la sentencia switch de Java.

Una definición de discriminator especifica los atributos column y javaType. Column indica de dónde debe MyBatis obtener el valor con el que comparar. El javaType es necesario para asegurar que se utiliza el tipo de comparación adecuada (aunque la comparación de Strings posiblemente funcione casi en todos los casos). Por ejemplo:

<resultMap id="vehicleResult" type="Vehicle">
  <id property="id" column="id" />
  <result property="vin" column="vin"/>
  <result property="year" column="year"/>
  <result property="make" column="make"/>
  <result property="model" column="model"/>
  <result property="color" column="color"/>
  <discriminator javaType="int" column="vehicle_type">
    <case value="1" resultMap="carResult"/>
    <case value="2" resultMap="truckResult"/>
    <case value="3" resultMap="vanResult"/>
    <case value="4" resultMap="suvResult"/>
  </discriminator>
</resultMap>

En este ejemplo, MyBatis obtendrá cada registro del ResultSet y comparará su valor vehicle_type. Si coincide con alguno de los casos del discriminador entonces usará el ResultMap especificado en cada caso. Esto se hace de forma exclusiva, es decir, el resto del ResultMap se ignora (a no ser que se extienda, de lo que hablaremos en un Segundo). Si no coincide ninguno de los casos MyBatis utilizará el resultmap definido fuera del bloque discriminator. Por tanto si carResult ha sido declarado de la siguiente forma:

<resultMap id="carResult" type="Car">
  <result property="doorCount" column="door_count" />
</resultMap>

Entonces solo la propiedad doorCount se cargará. Esto se hace así para permitir grupos de discriminadores completamente independientes, incluso que no tengan ninguna relación con el ResultMap padre. En este caso sabemos que hay relación entre coches y vehículos, dado que un coche es-un vehículo. Por tanto queremos que el resto de propiedades se carguen también, así que con un simple cambio en el ResultMap habremos terminado.

<resultMap id="carResult" type="Car" extends="vehicleResult">
  <result property="doorCount" column="door_count" />
</resultMap>

Ahora, se cargarán todas las propiedades tanto de vehicleResult como de carResult.

Nuevamente, hay quien puede pensar que la definición externa es tediosa. Por tanto hay una sintaxis alternativa para los que prefieran un estilo más conciso. Por ejemplo:

<resultMap id="vehicleResult" type="Vehicle">
  <id property="id" column="id" />
  <result property="vin" column="vin"/>
  <result property="year" column="year"/>
  <result property="make" column="make"/>
  <result property="model" column="model"/>
  <result property="color" column="color"/>
  <discriminator javaType="int" column="vehicle_type">
    <case value="1" resultType="carResult">
      <result property="doorCount" column="door_count" />
    </case>
    <case value="2" resultType="truckResult">
      <result property="boxSize" column="box_size" />
      <result property="extendedCab" column="extended_cab" />
    </case>
    <case value="3" resultType="vanResult">
      <result property="powerSlidingDoor" column="power_sliding_door" />
    </case>
    <case value="4" resultType="suvResult">
      <result property="allWheelDrive" column="all_wheel_drive" />
    </case>
  </discriminator>
</resultMap>

NOTA Recuerda que todos estos son ResultMaps, y que si no indicas ningún result en ellos, MyBatis mapeará automáticamente las columnas a las propiedades por ti. Así que en muchos casos estos ejemplos son más verbosos de lo que realmente debieran ser. Dicho esto, la mayoría de las bases de datos son bastante complejas y muchas veces no podemos depender de ello para todos los casos.

Como usar una caché personalizada

Además de poder personalizar la caché de las formas indicadas, puedes sustituir el sistema de caché por completo y proporcionar tu propia caché, o crear un adaptador para cachés de terceros.

<cache type="com.domain.something.MyCustomCache"/>

Este ejemplo muestra cómo usar una caché personalizada. La clase especificada en el atributo type debe implementar el interfaz org.apache.ibatis.cache.Cache y proporcionar un constructor que recibe como parámetro un String id. Este es uno de los interfaces más complejos de MyBatis pero su funcionalidad es simple.

public interface Cache {
  String getId();
  int getSize();
  void putObject(Object key, Object value);
  Object getObject(Object key);
  boolean hasKey(Object key);
  Object removeObject(Object key);
  void clear();
}

Para configurar tu caché añade simplemente propiedades tipo JavaBean a tu implementación, y pasa las propiedades usando el elemento cache, por ejemplo el siguiente ejemplo llamará a un método “setCacheFile(String file)” en tu implementación de caché:

<cache type="com.domain.something.MyCustomCache">
  <property name="cacheFile" value="/tmp/my-custom-cache.tmp"/>
</cache>

Puedes utilizar propiedades JavaBean de cualquier tipo simple y MyBatis hará la conversión. And you can specify a placeholder(e.g. ${cache.file}) to replace value defined at configuration properties.

Since 3.4.2, the MyBatis has been supported to call an initialization method after it's set all properties. If you want to use this feature, please implements the org.apache.ibatis.builder.InitializingObject interface on your custom cache class.

public interface InitializingObject {
  void initialize() throws Exception;
}

NOTE Los parametros de configuración de la cache (eviction, read write..etc.) explicados anteriormente no aplican cuando se usa una caché personalizada.

Es importante recordar que la configuración de la caches y la instancia de caché está asociadas al namespace del fichero SQL Map. Y por tanto, a todas las sentencias del mismo namespace dado que la cache está asociada a él. Los statements pueden modificar cómo interactúan con la caché, o excluirse a sí mismos completamente utilizando dos atributos simples. Por defecto los statements están configurados así:

<select ... flushCache="false" useCache="true"/>
<insert ... flushCache="true"/>
<update ... flushCache="true"/>
<delete ... flushCache="true"/>

Dado que estos son los valores por defecto, no deberías nunca configurar un statement de esa forma. En cambio, utiliza los atributos flushCache y useCache si quieres modificar el valor por defecto. Por ejemplo en algunos casos quieres excluir los resultados de un caché particular de la caché, o quizá quieras que un statement de tipo select vacíe la caché. O de forma similar, puede que quieras que algunas update statements no la vacíen.

cache-ref

Recuerda que en la sección anterior se indicó que la caché de un namespace sería utilizada por statements del mismo namespace. Es posible que en alguna ocasión quieras compartir la misma configuración de caché e instancia entre statements de distintos namespaces. En estos casos puedes hacer referencia a otra caché usando el elemento cache-ref.

<cache-ref namespace="com.someone.application.data.SomeMapper"/>