.net - Cambio de "esquema" en RavenDB

ravendb vs mongodb

Question

Solo por el interés de expandir mi conocimiento, comencé a buscar en varias opciones NoSQL. El primero que visité es RavenDB y parece interesante. Todavía estoy intentando romper mi pensamiento relacional profundo, junto con las rutinas típicas de mantenimiento de RDBMS.

En mi trabajo diario con Entity Framework, pasamos por la rutina de los cambios de la base de datos de scripts, la actualización del modelo de mapeo EF, etc. ¿Cómo funciona en NoSQL, especialmente en RavenDB? Una vez que una aplicación ha cobrado vida, ¿cómo se realizan cambios en los diversos objetos POCO, etc. y se implementan en producción? ¿Qué pasa con los datos almacenados en las antiguas clases de POCO?

Todavía no he profundizado ni he usado Raven DB enojado. Esto puede ser obvio una vez que lo haga, pero me encantaría saberlo antes, así que no me encierro en una esquina.

Gracias: D.

Answer 1

Este artículo de Ayende describe cómo realizar una migración de 1 a la versión 2 (en este caso, cambiar una propiedad "Nombre" a las propiedades "Nombre" y "Apellido").

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

Básicamente, un oyente está registrado en el DocumentStore:

documentStore.RegisterListener(new CustomerVersion1ToVersion2Converter())

Ejemplo de empalme tomado 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 2

No tiene tanta administración de esquemas como moverlo a su código para que nunca haya una discrepancia entre los objetos en su código y aquellos en su base de datos.

La primera parte de la gestión de cambios es asegurarse de que utiliza un serializador que puede manejar valores extra / extraviados: si un campo no está definido en los datos, configúrelo en nulo. 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 más que eso: o bien hay un nuevo campo y necesita tener un valor predeterminado para los registros existentes de todos modos, o hay un campo antiguo que ya no le importa.

Para cambios más complejos, como cambiar el nombre / combinación de 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 puede dejarse en su lugar permanentemente, actualizando 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 se necesita mucho tiempo para ejecutarse en un conjunto de datos grande, porque el código puede manejar formatos antiguos y nuevos.

Answer 3

Permanecen como están: las propiedades que ya no se ignorarán cuando se carguen (y se pierdan con el cambio), y las propiedades que faltan volverán como nulas,

Le recomendamos que utilice operaciones basadas en conjuntos para mantener los datos bajo control con el modelo de objetos.

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

Así que básicamente, al pasar a un almacén de documentos, está en lo correcto al reconocer que pierde alguna funcionalidad y obtiene algo de libertad en que en una base de datos tiene definido un esquema inicial e intenta cargar datos que no coincidan con ese esquema. dar como resultado un error.

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

Esto lo hace útil para el factor de "solo ponerse en marcha" de escribir un código y mantener sus datos persistentes, pero al ser tan fácil de cambiar la estructura de su código puede ser más difícil conciliar eso con sus datos ya existentes.

Algunas estrategias se presentan en este punto:

• Haz que tu estructura sea inmutable una vez que hayas conservado los datos, versiona tus clases
• Permite la modificación de la estructura, pero utiliza operaciones basadas en conjuntos para actualizar los datos para que coincidan con la nueva estructura
• Permitir la modificación de la estructura y escribir código para lidiar con inconsistencias al cargar datos

La tercera es claramente una mala idea ya que conducirá a un código que no se puede mantener, la versión de sus clases puede funcionar si solo está almacenando eventos u otros datos similares, pero no es realmente apropiado para la mayoría de los escenarios, por lo que le queda el medio opción.

Recomendaría hacer eso y seguir unas cuantas reglas simples en la misma línea que seguiría al tratar con un esquema inicial en una base de datos relacional.

• Use su sistema VCS para determinar los cambios entre las versiones implementadas
• Escribir scripts de migración que actualicen de una versión a otra
• Tenga cuidado al renombrar / eliminar propiedades, ya que cargar un documento y guardar el documento provocará la pérdida de datos si esas propiedades no existen en el nuevo documento

Etc.

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

Answer 4

RavenDB serializa tus 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, a los objetos que ya ha almacenado les faltarán esas propiedades.