Cambiar "esquema" en ravendb

Question

Solo por el interés de expandir mi conocimiento, he comenzado a mirar varias opciones NoSQL. El primero que visité es RavendB y parece interesante. Todavía estoy tratando de romper mi pensamiento relacional profundamente arraigado, junto con las típicas rutinas de mantenimiento de RDBMS.

En mi trato diario con el marco de la entidad, pasamos por la rutina de los cambios en la base de datos, refrescando el modelo de mapeo EF, etc. ¿Cómo funciona en cosas de NoSQL, especialmente RavendB? Una vez que una aplicación ha pasado la vida, ¿cómo se hace cambios en los diversos objetos POCO, etc. y la implementa en producción? ¿Qué suceden con los datos almacenados en las viejas clases de POCO?

No he profundizado o usado Raven DB con ira todavía. Esto puede ser obvio una vez que lo haga, pero me encantaría saber de antemano para que no me codifique en una esquina.

Gracias: D.

Answer 1

Se quedan como son: las propiedades que ya no existen serán ignoradas cuando se carguen (y se pierdan en el cambio), y las propiedades faltantes volverán como nulas,

Recomienda que use operaciones basadas en establecimientos para mantener los datos en control con el modelo de objeto.

¡Oh, mírame, estoy en una computadora ahora!

Básicamente, así que al mudarse a un almacén de documentos, tiene razón al reconocer que pierde algo de funcionalidad y obtiene algo de libertad en la que en una base de datos tiene un esquema inicial definido e intenta cargar datos que no coincidan con ese esquema. resultar en un error.

Sin embargo, es importante reconocer que existe una diferencia entre sin esquema y sin estructura, ya que todos sus documentos contienen su propia estructura (pares de clave/valor que denotan el nombre de la propiedad y el valor de la propiedad).

Esto lo hace útil para todo el factor "Just Getting" de escribir algún código y que persistan sus datos, pero cuando es tan fácil cambiar su estructura de código, puede ser más difícil conciliar eso con sus datos ya persistidos.

Algunas estrategias se presentan en este punto:

• Haga que su estructura sea inmutable una vez que haya persistido datos, versión sus clases
• Permitir la modificación de la estructura, pero use operaciones basadas en establecimientos para actualizar datos para que coincidan con una nueva estructura
• Permitir la modificación de la estructura y escribir código para tratar con inconsistencias al cargar datos

El tercero es claramente una mala idea, ya que conducirá a un código no mantenible, las versiones de sus clases pueden funcionar si solo almacena eventos u otros datos similares, pero no es realmente apropiado para la mayoría de los escenarios, por lo que te queda con el medio opción.

Recomendaría hacer exactamente eso y seguir algunas reglas simples en la misma línea que seguiría cuando se trata de un esquema inicial en una base de datos relacional.

• Use su sistema VCS para determinar los cambios entre versiones implementadas
• Escriba scripts de migración que se actualicen de una versión a otra
• Tenga cuidado con los renombres/las propiedades de eliminación: ya que cargar un documento y guardar el documento dará como resultado datos perdidos si esas propiedades no existen en el nuevo documento

Etc.

Espero que esto sea más útil :-)

Answer 2

RavendB esenciare sus objetos .NET al formato JSON. No hay esquema.

Si agrega algunos objetos a su base de datos, se serializarán. Si agrega algunas propiedades al tipo que está serializando, los objetos que ya ha almacenado se perderán esas propiedades.

Answer 3

Este artículo de Ayende describe cómo realizar una migración de 1 a la versión 2 (en este caso, cambiando una propiedad de "nombre" a las propiedades "FirstName" y "LastName".

http://ayende.com/blog/66563/ravendb-migrations-rolling-updates

Básicamente, un oyente está registrado en la tienda de documentos:

documentStore.RegisterListener(new CustomerVersion1ToVersion2Converter())

Impementación de muestra tomada del artículo mencionado anteriormente:

public class CustomerVersion1ToVersion2Converter : IDocumentConversionListener
{
    public void EntityToDocument(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;

        metadata["Customer-Schema-Version"] = 2;
        // preserve the old Name property, for now.
        document["Name"] = c.FirstName + " " + c.LastName;
        document["Email"] = c.CustomerEmail;
    }

    public void DocumentToEntity(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;
        if (metadata.Value<int>("Customer-Schema-Version") >= 2)
            return;

        c.FirstName = document.Value<string>("Name").Split().First();
        c.LastName = document.Value<string>("Name").Split().Last();
        c.CustomerEmail = document.Value<string>("Email");
    }
}

Answer 4

No tiene tanto que no tenga gestión de esquemas para moverlo a su código, por lo que nunca hay un desajuste entre los objetos en su código y los de su base de datos.

La primera parte de los cambios en el manejo es asegurarse de usar un serializador que pueda manejar valores faltantes/adicionales: si un campo no está definido en los datos, configúrelo en NULL. Si un campo en los datos no coincide con una propiedad en su objeto, ignórelo.

La mayoría de los cambios se pueden manejar sin nada más que eso, o de todos modos hay un campo nuevo y debe tener un valor predeterminado para los registros existentes, o hay un campo antiguo que ya no le importa.

Para cambios más complejos, como renombrar/combinar campos o cambiar el formato de datos, agregue un nuevo campo a su objeto sin eliminar los antiguos y haga que su método de carga transfiera datos de los campos antiguos. Cuando guarde el registro, estará en el nuevo formato. Este código se puede dejar en su lugar permanentemente, actualizar los datos según sea necesario, o puede configurar un proceso único para llamar al mismo código para todos los objetos existentes. Tenga en cuenta que, a diferencia de un script SQL, no se requiere tiempo de inactividad para este tipo de actualización, incluso si lleva mucho tiempo ejecutarse en un conjunto de datos grande, porque el código puede manejar formatos antiguos y nuevos.