# Qué son las migraciones de datos

si cambiamos un campo de nombre por el morro, sin versiones ni migración explícita, el campo no se renombra, se crea una columna nueva y se borra la antigua, así que los datos antiguos pierden ese campo

## Qué son las migraciones de datos

A lo largo del ciclo de desarrollo de una aplicación, conforme le vayamos añadiendo funcionalidades es habitual que el modelo de datos vaya creciendo: iremos añadiendo entidades y/o relaciones, o atributos a entidades. En otros casos tendremos que *refactorizar* el modelo porque nos habremos dado cuenta de que hay ciertas cosas mejorables: quizá tenemos que eliminar atributos, o renombrarlos, o fusionar o dividir entidades, ... Es decir, el modelo de datos va a ir evolucionando en el proceso de desarrollo, incluso después de lanzar la primera versión de la aplicación en la App Store.

El problema que se plantea al cambiar el modelo de datos existente es *qué hacer con los datos que ya tenemos*. Por ejemplo si decidimos añadir un nuevo atributo debemos pensar qué hacer con los datos que ya existen y que no tienen valor asignado para él. Una solución drástica sería comenzar de cero, borrar todos los datos y empezar de nuevo. En desarrollo basta con ir al directorio donde Core Data guarda la base de datos SQLite y eliminarla manualmente (en el directorio `Library/Application Support` donde reside la aplicación). Pero evidentemente no podemos decirle a un usuario que al instalar la versión 2.0 de nuestra *app* va a perder todos sus datos. Hay que definir algún procedimiento para transformar los datos ya existentes a la nueva versión del modelo. A este procedimiento de "traslado" se le llama **migración de datos**. Por ejemplo en el caso del nuevo atributo el procedimiento podría ser tan simple como dar un valor por defecto a los datos antiguos, o dejarlo vacío, dependiendo de los requerimientos de la aplicación.

En la documentación de Apple se distinguen dos tipos de migraciones: las migraciones **ligeras** (*lightweight*) y las migraciones "a secas" o **manuales** (o en algunos sitios llamadas *pesadas* por contraposición a las ligeras). Las primeras son automáticas o semiautomáticas, requiriendo en general poco trabajo por nuestra parte o ninguno. Para las segundas vamos a tener que realizar la transformación de datos de forma manual, generalmente escribiendo código que indique cómo transformar los datos antiguos al nuevo "formato".

En esta sesión vamos a ver cómo hacer migraciones de los dos tipos, pero antes vamos a ver cómo "decirle" a Core Data que queremos modificar el modelo.
