O bruxo mobile

DDD, agregados y NoSQL

Unai — Mon, 30 Jan 2012 19:35:35 GMT

En la segunda entrada que se publico en este blog sobre RavenDB se hizo una pequeña mención, no demasiado grande la verdad, a la forma en la que tenemos que diseñar nuestros documentos en una base de datos NoSQL. La verda es que esto, no es muy sencillo para aquellos que empiezan a trabajar en una base de datos no relacional, puesto que pasar de diseñar tablas y sus relaciones a documentos sin relaciones es un cambio importante, muy importante diría yo. Todos sabemos que un documento no tiene porque ser una estructura sencilla, sino, que puede ser una agregación de otras entidades, pero ¿cual es el punto en el que rompemos esa agregación o cluster de entidades?

La siguiente imagen nos muestra un posible diseño de un documento para una estructura de producto, backlog items, task, sprint etc…en el que se ha decidido crear un único tipo de documento que aglutine esta información, la imagen se ha extraído del Management Studio de Raven DB, pero lo mismo se aplicaría a cualquier base de datos documental como MongoDB etc..

Independientemente de la que los atributos del documento sean más o menos reales o que falte algo de información ¿es este un buen diseño de documento? ¿Deberíamos hacer documentos más pequeños y, si es así, cual es la referencia/técnica que debemos utilizar?

La respuesta que yo siempre intento dar es asimilar el diseño de documentos con los mismos conceptos que utilizamos en DDD con Aggregate Roots. Cuando uno empieza a trabajar con agg roots ( un concepto facil de explicar pero dificil de poner en la práctica ), tiene prácticamente las mismas dudas e inquietudes, y casi siempre, estas se resuelven pensando en invariants y consistency boundary en vez de elementos composicionales, como por ejemplo podría haber sido nuestro caso en el que se ha pensado en la composición de un producto sobre cualquier otro concepto. Si en vez de forma composicional pensaramos en consistencia transaccional y la preservación de invariantes nos daríamos cuenta de como un agregado tan grande como el nuestro provocaría infinidad de transacciones erroneas puesto que en el negocio es habitual que varias personas por ejemplo se dedicaran a incluir nuevos backlogitems de forma concurrente, etc etc…

Por supuesto, la otra alternativa a hacer un agregado de grandes dimensiones como este, sería definir agregados por entidad, es decir, múltiples agregados, pero.. ¿es esta la vía correcta? Aquí en realidad, incurrimos en el mismo error que el anterior, no pensar en invariantes consistencia. Sigamos con el ejemplo, ¿tiene sentido separar un producto de sus backlogItems? ¿hay algún invariante que mantener? Si lo piensa, seguramente podríamos separarlo sin más problemas y esto, incurriría en muchas ventajas para nosotros puesto que los errores de concurrencia que teníamos antes desaparecerían fácilmente.. pero, siguiendo con un ejemplo similar ¿tiene sentido separar un pedido y sus lineas de pedido?¿hay invariantes y/o consistencia transaccional que mantener?.

Seguramente ya ha notado la diferencia entre ámbos casos ¿verdad?¿ seguro? Pues bien, esta es la forma de pensar a la hora de diseñar los agregados, pensando en los invariantes y la consistencia, intentando siempre que sean lo más finos posible.

El trabajo con los documentos es un nuevo aprendizaje para muchos, y durante este aprendizaje, como en todos, cometeremos errores. Espero que con este posts y con las consiguientes referencias bibliográficas el número de errores a cometer sea el mínimo posible. Por supuesto, dependiendo de su NoSQL documental preferida tendrá ventajas a la hora de trabajar el diseño de documentos y su trabajo, el manejo de la concurrencia o las referencias podrían ser unas de las características a revisar en su motor.

Referencias

Excelente serie sobre diseño de agregados de Vaughn Vernon:http://www.shiftmethod.com/publications

Domain Driven Design, Aggregates: http://domaindrivendesign.org/node/88

Saludos

Unai

EF 4.3 Beta 1: más madera….y un pequeño extra…

Unai — Thu, 12 Jan 2012 23:20:00 GMT

Cuando se publique este post habrá salido ya el anuncio de la primera beta de ADO.NET EF 4.3 en el blog del equipo de producto de ADO.NET. Los que me leeis con asiduidad sabréis que si solamente es para poner una reseña no suelo escribir una entrada o sea que trataré de dar mi punto de vista sobre esta nueva beta y algunas cosillas extras que no salen publicadas en los diferentes walkthrough.

Bien, antes de empezar con las novedades, que enumeraremos a continuación, es importante decir que esta será la última versión de EF hasta la llegada de EF 5.0 con la siguiente entrega de .NET Framework, en la que el código base, es decir, System.Data.Entity, por fin abrirá más puertas para introducir más y más importantes mejoras. Como acabamos de comentar, de entre las novedades mñas importantes que podemos encontrar en esta version tenemos los siguientes elementos, para el resto de información, revisar la entrada del grupo de producto aquí.

Inclusión del paquete de Migraciones dentro del código base de EntityFramework.dll
Resueltos un par de bugs, revisar el post del grupo de producto
Una nueva sección de configuración que nos permitirá establecer inicializadores y configurar la DefaultConnectionFactory que utilizaremos por defecto

Migraciones es ahora parte de EF

Como ya comentamos en esta anterior entrada desde esta versión EF incluye por defecto el paquete de migraciones, sin tener, como hasta ahora que incluir en NuGet EntityFramework.Migrations como hasta ahora. En realidad, el funcionamiento es el mismo que hasta ahora, pero, con unos pequeños ligeros cambios en los comandos de power shell y la eliminación de la convención IncludeMetadataConvention. Como siempre, lo mejor es verlo todo en la práctica o sea que vamos a ello. Crearemos, como hacemos habitualmente, un proyecto tonto de demo que nos permitirá ir viendo cosillas.

Lo primero será incluir el paquete de EF 4.3, puesto que es beta, al igual que se ha hecho con otros paquetes, tenemos que incluir en el comando de instalación la opcion IncludePreRelease aunque también suelen funcionar PreRelease y Pre simplemente.

Una vez incluído el paquete de la beta, crearemos nuestra unidad de trabajo, un ejemplo sencillo, tal y como hacemos habitualmente:

public class Author

    public int Id { get; set; }

    public string Name { get; set; }

public class Blog

    public int Id { get; set; }

    public string Title { get; set; }

    public string AboutBlog { get; set; }

public class BlogEngineUnitOfWork

    :DbContext

    public DbSet<Author> Authors { get; set; }

    public DbSet<Blog> Blogs { get; set; }

Tal y como sabréis todos a estas alturas, si utilizaramos la unidad de trabajo anterior, se nos generaría una nueva base de datos para el modelo dado, ahora, este proceso será el mismo, pero con un importante cambio y es que el proceso de creación de la base de datos se hace utilizando el API de Migrations, para ello basta con fijarse que ya no tenemos la tabla de metadata típica y sin embargo, en las tablas de sistema podemos ver una nueva llamada __MigrationHistory, tal y como se ven en la imagen de la derecha.

Bueno, aunque esto sea así, por defecto, el sistema de migraciones no está habilitado en nuestros cambios de dominio, para ello, tenemos que ejecutar el comando Enable-Migrations. Este comando, tiene el mismo efecto que tenía en anteriores versiones incluir el paquete de migraciones, es decir, nos agrega una nueva carpeta llamada Migrations en la que tendremos la configuración del sistema de migraciones y se incluirá el código de las distintas migraciones que vayamos haciendo. En realidad aquí no hay nada nuevo a lo que ya conocíamos, aunque para ser sincero tampoco he revisado el conjunto de propiedades que DbMigrationsConfiguration pone a nuestra disposición.

Bien, una vez habilitadas las migraciones pasaremos a crear(actualizar) la base datos, otra vez, como ya sabíamos tenemos el comando Update-Database con sus diferentes opciones, os recomiendo mirar el get-help Update-Database –detailed para una completa información de todo lo que podemos hacer. Por ahora, al habilitar las migraciones ya tendremos la base de datos generada y por lo tanto, el comando nos dirá que no tiene tareas pendientes o sea que empezaremos agregando una nueva propiedad a Blog, por ejemplo CreationDate, como vemos en el siguiente fragmento.

public class Blog

    public int Id { get; set; }

    public string Title { get; set; }

    public string AboutBlog { get; set; }

    public DateTime CreationDate { get; set; }

Una vez agregada esta propiedad, agregaremos una migración, para ello, usaremos otra vez el ya conocido comando Add-Migration, el cuál, incluye en la carpeta de migraciones el código de la nueva migración, que yo he llamado AddedCreationDate y que contiene algo similar a lo siguiente:

public partial class AddedCreationDate : DbMigration

    public override void Up()

        CreateTable(

            "Authors",

            c => new

                    Id = c.Int(nullable: false, identity: true),

                    Name = c.String(),

})

            .PrimaryKey(t => t.Id);

        CreateTable(

            "Blogs",

            c => new

                    Id = c.Int(nullable: false, identity: true),

                    Title = c.String(),

                    AboutBlog = c.String(),

                    CreationDate = c.DateTime(nullable: false),

})

            .PrimaryKey(t => t.Id);

    public override void Down()

        DropTable("Blogs");

        DropTable("Authors");

Por supuesto, también, como ya sabrá de anteriores entradas podemos hacer otras tareas como la creación de índices etc, como vemos en la lista de métodos que DbMigration pone a nuestra disposición:

AddColumn
AddForeignKey
AddPrimaryKey
AlterColumn
CreateIndex
CreateTable
DropColumn
DropForeignKey
DropIndex
DropPrimaryKey
DropTable
MoveTable
RenameColumn
RenameTable
Sql

La nueva sección de configuración

Como comentábamos antes,aquí va el punto extra, y es que EF 4.3 pone a nuestra disposición a una nueva sección de configuración, EntityFrameworkSection, gracias a la cual podremos configurar desde el DefaultConnectionFactory que queremos tener por defecto ( antes teníamos que recurrir a Database.DefaultConnectionFactory ) hasta los inicializadores que queremos tener por defecto. A continuación os pongo un fragmento de una sección de configuración sobre un contexto de trabajo en el que se establece un inicializador y en la que además se establece una factoria de conexión por defecto.

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <configSections>

    <section name="entityFramework"

         type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

  </configSections>

  <entityFramework>

    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">

      <parameters>

        <parameter value="Data Source=.; Integrated Security=True; MultipleActiveResultSets=True" />

      </parameters>

    </defaultConnectionFactory>

    <contexts>

      <context type="MySample.UnitOfWork,MySample">

        <databaseInitializer type="MySample.MyCustomInitializer,MySample" />

      </context>

    </contexts>

  </entityFramework>

</configuration>

Como veis el equipo de ADO.NET está trabajando duro y esto es algo que podemos ver de forma temprana gracias a que los paquetes de EF nuevos no forman parte del Framework. Os imaginais que pasaría si EF se fuera a un modelo como el de MVC en el que no tienen una dependencia con el framework… ummmm

Saludos

Unai

P&P y CQRS: Guía + implementación de ejemplo

Unai — Thu, 12 Jan 2012 22:57:08 GMT

Bueno, una entrada cortita, la gente de Patterns and Practices han lanzado una encuesta valorando los intereses y conocimientos de la gente referidos a CQRS. El caso es que Grigori, Eugenio, Cesar de la torre y compañia están preparando una guia y probablemente una implementación de ejemplo de CQRS y quieren preguntarnos por nuestras inquietudes y preferencias antes de continuar…

Si te gusta CQRS entra en la encuesta y participa, si te interesa o crees que es bueno esta nueva guia lo mismo, participa aquí

Gracias

Unai

EF 4.X: Sql Federations

Unai — Thu, 12 Jan 2012 17:53:30 GMT

Para los que estéis al dia de todo lo que ocurre con Windows Azure y las distintas features que están poniendo habréis visto que entre node.js, linux y otras lindezas se está planeando liberar una release de Sql Azure Federation, vamos, lo que toda la vida se ha llamado la capacidad de “sharding” . Sino me equivoco, Ibon estará más enterado que yo y podría corregirme, esta feature saldra en el Q4 del 2011, es decir a finales de año. Llegados aquí, a muchos, yo entre ellos, se preguntarán si nos cambia algo la vida en cuanto al desarrollo y por supuesto, los que utilizamos un ORM como EF nos lo preguntamos con mayor preocupación todavía.

Después de leer la documentación y demás sobre como está formado Azure Federations la cosa se vuelve un poquito preocupante, sobre todo porque por ejemplo tendremos que renunciar a las capacidades que nos da EF para autogenerarnos una base de datos a partir del modelo, puesto que ahora, tendremos que especificar en la creación elementos como la federación etc, a mayores de crear la federación. Es decir, antes de generar la base de datos deberíamos tener cosas como las siguientes:

CREATE FEDERATION FED_1 (range_id BIGINT RANGE) GO

USE FEDERATION FED_1 (range_id = 0) WITH FILTERING = OFF, RESET GO

CREATE TABLE Orders

    order_id bigint not null,

    customer_id bigint,

    total_cost money not null,

    order_date datetime not null,

    primary key (order_id, customer_id)

) FEDERATED ON (range_id = customer_id)

GO

Bien, esto de por si ya implica una pequeña restricción, la pena, es que esta no es la única, puesto que en nuestras consultas tendremos que hacer un pequeño trabajo para establecer sobre que miembro del sharding pueden trabajar. Por suerte para nosotros, el grupo Windows Azure Customer Advisory Team ~~( tiene narices que la web sea php )~~ ha creado un pequeño manual de como debemos de trabajar que sin duda nos será de mucha ayuda el cual lo podeís encontrar aquí

Espero que os sea de interés…

Saludos

Unai

RavenDB VII Consultas e indices estáticos..

Unai — Tue, 20 Dec 2011 18:26:00 GMT

Map

En la anterior entrada hicimos la primera introducción de lo que considero uno de los puntos fuertes, a mayores del API cliente, de RavenDB y este no es otro que su sistema de consultas. En esta entrada, hicimos una introducción sobre los índices que utiliza por detras RavenDB y que, como ya sabemos, se basan en Lucene.NET. Pero, los índices que vimos, eran dinámicos o bien generados automáticamente por RavenDB, si detecta un numero alto de consultas sobre el temporal. Estos índinces dinámicos no suelen ser una buena solución porque pueden tener una alta latencia, se ejecutan al vuelo y por lo tanto pueden tener un tiempo de ejecución alto, y no son demasiado flexibles en cuanto a las necesidades que podemos tener, trabajo con datos espaciales, búsquedas de texto completo, proyecciones etc.

Un índice estático no es más que la definición de una estructura llamada Raven.Abstractions.Indexing.IndexDefinition cuyo cuerpo podemos ver a continuación:

public class IndexDefinition

    public IndexDefinition();

    public IDictionary<string, string> Analyzers { get; set; }

    public IList<string> Fields { get; set; }

    public IDictionary<string, FieldIndexing> Indexes { get; set; }

    public bool IsCompiled { get; set; }

    public bool IsMapReduce { get; }

    public bool IsTemp { get; }

    public string Map { get; set; }

    public HashSet<string> Maps { get; set; }

    public string Name { get; set; }

    public string Reduce { get; set; }

    public IDictionary<string, SortOptions> SortOptions { get; set; }

    public IDictionary<string, FieldStorage> Stores { get; set; }

    public string TransformResults { get; set; }

    public string Type { get; }

    public bool Equals(IndexDefinition other);

    public override bool Equals(object obj);

    public override int GetHashCode();

    public byte[] GetIndexHash();

    public void RemoveDefaultValues();

Si observa la definición anterior, hay una serie de puntos muy interesantes, como son los miembros Map, Reduce, TransformResult y Analyzers. A lo largo de esta entrada, intentaremos, aunque sea de forma somera, ver todos y cada uno de ellos, seguramente juntándolos con algún otro elemento necesario. Aunque es posible crear directamente esta estructura, por lo general, la misma se suele crear a partir de una clase llamada IndexDefinitionBuilder, como podemos ver en el siguiente ejemplo de código.

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    store.DatabaseCommands.PutIndex("PostByTitle", new IndexDefinitionBuilder<Post>()

        Map = posts => from p in posts

                       select new { p.Title }

});

Con esto acabamos de ordenar al servidor de RavenDB crear un nuevo índice, llamado PostByTitle,sobre la colección de posts, utilizando para ellos los métodos de comandos de base de datos que nos ofrece nuestra interface IDocumentStore. Para el índice anterior podemos ver como hacer la búsqueda de los documentos que nos interesan y a mayores sobre que campos vamos a hacer la búsqueda de nuestros documentos, en este caso solamente la propiedad Title.

Ahora, si quisiéramos hacer una consulta sobre este índice podríamos hacer algo tal cual lo que vemos en el siguiente tip de código:

RavenQueryStatistics statistcs;

var result = session.Query<Post>("PostByTitle")

                    .Statistics(out statistcs)

                    .Where(p => p.Title != "O bruxo mobile...")

                    .Take(100)

                    .ToList();

Analyzers

Bueno, parece que más o menos está claro, sin embargo, seguro que a muchos se os ocurren algunas preguntas. La primera que a mi me vino a la mano, es como es la creación de ese índice en el campo Title, es decir, la tokenización de los valores se puede hacer de muchas maneras, desechando terminos terminales, pudiendo poner sinónimos, etc…. Seguramanete, esta pregunta me la hice porque no conocía demasiado bien el concepto de Analizadores en Lucene.NET. Pues bien, una vez comprendidos los analizadores la siguiente pregunta es ver ¿como podemos decirle a los índices de RavenDB que ciertos campos estén marcados por un analizador? Pues si revisamos el codigo de creación de nuestro índice podemos ver lo sencillo que resulta esta tarea, como se puede ver a continuación.

store.DatabaseCommands.PutIndex("PostByTitle", new IndexDefinitionBuilder<Post>()

    Map = posts => from p in posts

                   select new { p.Title },

    Analyzers =

        {pp=>pp.Title,typeof(StandardAnalyzer).FullName}

});

Observe como el diccionario Analyzers nos permite, de una forma bastante sencilla, incorporar una analizador específico a uno de los campos del Map. Puesto que nos pide el nombre de un tipo de analizador una forma sencilla de hacerlo sin tener que acordarse de todo el fullname es referenciar al tipo y extraer su FullName. Este tipo, está en la librería Lucene.NET que tendrá que referenciar puesto que no forma parte del API cliente de RavenDB.

Bien, puesto que seguramente, si ha seguido este post y ha modificado el índice se habrá dado cuenta de que una vez creado no podemos volver a ejecutar PutIndex, puesto que esto falla, al existir uno lógicamente. Para prevenir estos casos y hacer el bootstraping de los índices de una forma más sencilla, RavenDB nos ofrece un mecanismo alternativo que pasaremos a comentar a continuación. Con el fin de facilitar la definición y reutilización de indices RavenDB nos propone definir los mismos en una clase que extienda AbstractIndexCreationTask<TDocument> como por ejemplo podría ser la siguiente:

public class PostByTitleIndex

    :AbstractIndexCreationTask<Post>

    public PostByTitleIndex()

        Map = posts => from p in posts

                       select new { p.Title };

        Analyzers.Add(pp => pp.Title, typeof(StandardAnalyzer).FullName);

Ahora, para hacer el botstrapper solamente tendríamos que ejecutar la siguiente instrucción, sin preocuparnos si los indices son nuevos, modificaciones de los existentes o ya existen con esa misma definición.

IndexCreation.CreateIndexes(typeof(PostByTitleIndex).Assembly, store);

Reduce

Con lo anterior, aunque no sea muy profundamente, ya hemos terminado la parte referida al Map, pero como ya seguramente sabrá, y hemos dicho, esta no es la única parte importante de un índice puesto que también podemos especificar una función de Reduce. En palabras parcas, un Reduce es una paso posterior a la selección o mapeo de documentos, sobre la podemos hacer opero tstaciones ( asociativas ) de agregación. A mayores, la idea es que estas operaciones se puedan hacer sobre subconjuntos de los seleccionados, con el fin de paralelizarlas, por eso la consideración de que sean asociativas las funciones de agregación. Hay una muy buena referencia visual acerca de cual es la teoría de Map/Reduce en este post que seguro le introducirá en este aspecto de buena manera.

Una vez que nos hemos preocupado por saber que es un Reduce, concepto que por supuesto tenemos en todas las bases de datos documentales como MongoDB, por ejemplo, pasaremos a ver algún ejemplo de esta característica. Supongamos por ejemplo que deseamos obtener la suma de los comentarios agrupadas por identificador de blog, puesto que la “cuenta” es una operación asociativa, podríamos crear un índice como sigue:

public class CountByBlogIdIndex

    : AbstractIndexCreationTask<Post, RavenStaticIndex.CountByBlogIdIndex.CountByBlogIdIndexReduceResult>

    public class CountByBlogIdIndexReduceResult

        public string BlogId { get; set; }

        public int Count { get; set; }

    public CountByBlogIdIndex()

        Map = posts => from p in posts

                       select new { p.BlogId,p.Comments.Count };

        Reduce = result => from r in result

                           group r by r.BlogId

                           into temp

                           select new { BlogId = temp.Key, Count = temp.Sum(rr=>rr.Count) };

Y podríamos consultar esto de la siguiente forma en el API de RavenDB.

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    IndexCreation.CreateIndexes(typeof(CountByBlogIdIndex).Assembly, store);

    RavenQueryStatistics statistcs;

    var result = session.Query<RavenStaticIndex.CountByBlogIdIndex.CountByBlogIdIndexReduceResult, CountByBlogIdIndex>()

                        .Statistics(out statistcs)

                        .Take(100)

                        .ToList();

Bueno, creo que son ya bastantes cosas como para ponerse a jugar sin esperar más no?? yo creo que si, o sea que dejaremos para otra entrada algunas cosillas que nos faltan como multi-maps, funciones de transformación etc. etc..

Saludos

Unai

Raven DB VI, La hora de las consultas…

Unai — Mon, 19 Dec 2011 18:12:00 GMT

Por fin, seguro que ha sido la frase de muchos al oir que ya llegábamos a las consultas… Bien, pues si, con esta entrada inauguramos el trabajo con las consultas en RavenDB. Después ya de unos cuantos posts sobre el tema creo que ya es hora de tocar una de las cosas más importantes y que mejor hace RavenDB, que es las consultas.

Como siempre, ponemos un pequeño modelo de clase para realizar los distintos ejemplos. En esta occasion reutilizaremos las tipicas Blog, Post y Comment que ya hemos visto otras veces, y daremos por supuesto que tenemos ya una cantidad de documentos incluídos en RavenDB antes de procesar las consultas.

public class Blog

    public string Id { get; set; }

    public string Title { get; set; }

    public string About { get; set; }

public class Post

    public string Id { get; set; }

    public string BlogId { get; set; }

    public string Title { get; set; }

    public string Body { get; set; }

    public List<Comment> Comments { get; set; }

public class Comment

    public string Author { get; set; }

    public string Text { get; set; }

* Como ya se ha comentado alguna vez, los modelos de las entradas tienen una finalidad lectiva y por lo tanto no se tiene porque ajustar a la realidad

Por defecto, y en la práctica, toda consulta que hacemos a RavenDB representa un índice sobre el almacen de RavenDB utilizando el proyecto Lucene .NET. Lucene, es un motor de búsqueda basado en .NET, en realidad es un port de java, basado en un índice invertido que funciona realmente rápido y dispone de muchas características importantes. Por suerte, RavenDB no nos obliga a conocer la sintaxis de Lucene, aunque aprendiendo Lucene entenderíamos muchos de los comportamientos del motor de consultas, puesto que nos ofrece un completo soporte de Linq, pudiendo escribir todas nuestras consultas en Linq y dejando al API de cliente que se encargue de la traducción de las mismas a la sintaxis de Lucene.

Con el fin de mostrar el primer ejemplo, supongamos el siguiente código.

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    var post = (from c in session.Query<Post>()

                where c.Title != "RavenDB"

                select c).ToList();

En la consulta anterior podemos ver un ejemplo de consulta dinámica tal cual la podríamos hacer contra otro almacén como una colección de objetos o una tabla con EF. Lógicamente, esta consulta genera una petición http al servidor de RavenDB, en concreto, la siguiente petición:

GET http://ravenserver/indexes/dynamic/Posts?query=-Title%253ARavenDB%2520AND%2520Title%253A*&start=0&pageSize=128&aggregation=None HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8

Si examinamos la trama podemos observar los siguientes elementos:

Por defecto, las consultas se hacen sobre un indice, en este caso, como no hemos especificado cual se hace sobre un índice dinámico
Por defecto las consultas nos protegen contra resultados potencialmente grande, agregando por defecto un parámetro llamado pageSize , cuyo valor por defecto es 128.

Bien, la primera condición era algo que ya sabíamos, es decir, si RavenDB está basado en Lucene tiene que existir algún tipo de índece. RavenDB, puede generar un índice dinámico para aquellas consultas que no se hacen sobre un índice estático. A mayores, si considera que se ha utilizado una consulta un numero alto de veces, podría materializar el indice dinámico en un índice estático. Para provocarlo, realize esa consulta un número de veces y diríjase a nuestra herramienta de administración de RavenDB, Raven Management Studio y podrá ver algo similar a lo mostrado en la imagen de la derecha. Por supuesto, más adelante veremos como crear los índices de forma estática.

El otro punto que hacíamos notar es como RavenDB por defecto nos protegía de las consultas potencialmente grandes restringiendo el número de resultados a 128, puesto que, por defecto el valor de pageSize es este. Si, nosotros queremos traer un conjunto mayor de resultados podríamos hacer uso de este operador en la consulta, de forma similar a como vemos a continuación:

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    var post = session.Query<Post>()

                      .Where(c=>c.Title != "RavenDB")

                      .Take(200)

                      .ToList();

Otro nivel de protección que se incluye en RavenDB es que, por defecto, tampoco nos permite obtener más de 1000 resultados por consulta. En este caso, la protección no está en el cliente sino en el servidor y por lo tanto, modificar esto no es tan sencillo como acabamos de ver con el operador Take. Para hacerlo, tenemos que incluir en la configuración del servidor una nueva clave de configuración que se llama MaxPageSize.

<add key="Raven/MaxPageSize" value="2000"/>

A mayores, y como elemento de valor, RavenDB incluye algunos métodos de extensión a nuestras consultas que nos permitirán desde customizar las consultas hasta obtener información acerca de las mismas. El primero de los métodos que veremos es Statistics, gracias al cual podremos obtener información acerca del número total de documentos en la base de datos y otra información de valor.

using (IDocumentSession session = store.OpenSession())

    RavenQueryStatistics statistics;

    var post = session.Query<Post>()

                      .Statistics(out statistics)

                      .Where(c=>c.Title != "RavenDB")

                      .Take(200)

                      .ToList();

RavenQueryStatistics, nos ofrece, como puede observar, la siguiente información:

El nombre del índice que se ha utilizado en la consulta
Si los datos son state
El número total de documentos en la base de datos
El número de documentos omitidos ( hablaremos sobre esto)
La fecha de ejecución del índice
La fecha, a partir de la cual los datos son state

Un elemento importante de estas estadísticas es el de SkippedResults. Este valor nos ofrece la información de aquellos elementos que no se han tenido en cuenta para calcular el número total de resultados. Por ejemplo porque se ha aplicado una claúsula Distinct. Con esto, queremos decir que por ejemplo, si estamos paginando y hemos obtenido una primera pagina, incluyendo 5 en el valor de SkippedResults la siguiente página tendria que pedirse de la siguiente forma: pageCount + SkippedResults.

Otro de los métodos que podemos incluir en nuestras consultas es el método de Customize. En esta ocasión, este método no nos permite obtener más información sino que, nos permite customizar cierto grado de comportamiento de nuestras consultas. Imáginese por ejemplo que usted en una consulta dinámica no puede permitirse la consulta de datos state, pues bien, con Customize podemos indicar esto de una forma sencilla.

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    RavenQueryStatistics statistics;

    var post = session.Query<Post>()

                      .Statistics(out statistics)

                      .Customize(dqc=>dqc.WaitForNonStaleResultsAsOfNow())

                      .Skip(0)

                      .Take(10)

                      .ToList();

Si observa durante un momento los métodos de los que disponemos en IDocumentQueryCustomization , el tipo del parámetro de entrada en la Action que establecemos en Customize, podemos ver que disponemos de diferentes sobrecargas y posibilidades para la espera de resultados no state.

WaitForNonStaleResultsAsOf: Nos permite establecer una fecha de corte, que lógicamente no tiene porque ser en este momento, para el cual los datos no puedan ser stale. Por supuesto, también nos permite indicar un tiempo máximo de espera.
WaitForNonStaleResultsAsOfNow: Nos permite especificar la fecha de corte como ahora.
WaitForNonStaleResultsAsOfLastWrite: Nos permite especificar la fecha de corte como la última en la que se ha escrito por parte de la aplicación.
WaitForNonStaleResults: Nos permite indicar que el procesado de la query debe de esperar por resultados no stale. Podemos indicar un tiempo máximo de espera si deseamos no estar bloqueando at infinitum. Solamente se suele utilizar dentro de tests unitarios, tiene demasiadas implicaciones como para que exista su uso fuera de este ámbito.

La propina

Bueno, la entrada ya se acerca a su final. En la misma, hemos visto los principios de las consultas en RavenDB y los índices dinámicos. Para la siguiente entrada, hablaremos acerca de los índices estáticos, funciones map-reduce y analizadores. No obstante me gustaría dejar una pequeña propina…. fíjese en el siguiente código.

using(IDocumentStore store = new DocumentStore(){ConnectionStringName="Raven"}.Initialize())

using (IDocumentSession session = store.OpenSession())

    var post = session.Query<Post>()

                      .Include(p => p.BlogId)

                      .ToList();

Al igual que el método Include en EF, este método nos permite en RavenDB indicarle que además de la carga de los documentos de la consulte carge adicionalmente la referencia indicada, en nuestro caso el blog asociado, de esta manera, tras el siguiente request:

GET http://ravenserver/indexes/dynamic/Posts?query=&start=0&pageSize=128&aggregation=None&include=BlogId HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8

Podemos ver los siguientes resultados, dónde además de los post correspondientes se incluyen los Blogs referenciados.

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
ETag: c171861e-497b-1bc0-a8c1-78c1da9f6070
Server: Microsoft-IIS/7.5
Raven-Server-Build: 573
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Mon, 19 Dec 2011 18:08:59 GMT
Content-Length: 1589

{"Results":[{"BlogId":"blogs/1","Title":"The curegame, making off!","Body":"This is the first post about thecuregame..","Comments":[],"@metadata":{"Raven-Entity-Name":"Posts","Raven-Clr-Type":"RavenQueryI.Post, RavenQueryI","@id":"posts/1","Temp-Index-Score":1.0,"Last-Modified":"2011-12-19T17:06:05.6520000","@etag":"00000000-0000-0500-0000-000000000005","Non-Authoritive-Information":false}},{"BlogId":"blogs/2","Title":"The curegame, making off!","Body":"For me, this is the first entry about...","Comments":[],"@metadata":{"Raven-Entity-Name":"Posts","Raven-Clr-Type":"RavenQueryI.Post, RavenQueryI","@id":"posts/2","Temp-Index-Score":1.0,"Last-Modified":"2011-12-19T17:06:05.6520000","@etag":"00000000-0000-0500-0000-000000000006","Non-Authoritive-Information":false}}],"Includes":[{"Title":"O Bruxo mobile!","About":"About this blog post...","@metadata":{"Raven-Entity-Name":"Blogs","Raven-Clr-Type":"RavenQueryI.Blog, RavenQueryI","@id":"blogs/1","Last-Modified":"2011-12-19T17:03:56.0000000","@etag":"00000000-0000-0400-0000-000000000002","Non-Authoritive-Information":false}},{"Title":"La masa, el ladrillo, la bota y el bocadillo!","About":"About this blog post...","@metadata":{"Raven-Entity-Name":"Blogs","Raven-Clr-Type":"RavenQueryI.Blog, RavenQueryI","@id":"blogs/2","Last-Modified":"2011-12-19T17:03:56.0000000","@etag":"00000000-0000-0400-0000-000000000003","Non-Authoritive-Information":false}}],"IsStale":false,"IndexTimestamp":"2011-12-19T17:06:05.6520000","TotalResults":2,"SkippedResults":0,"IndexName":"Temp/Posts","IndexEtag":"00000000-0000-0500-0000-000000000006"}

Saludos y hasta la siguiente entrada,

Unai

RavenDB(V) Actualizaciones, concurrencia, patch y otras hierbas

Unai — Thu, 15 Dec 2011 20:05:16 GMT

En esta quinta entrega de la serie, puede ver las anteriores entradas aquí, I,-II-III y IV, vamos a hablar sobre actualizaciones y los mecanismos de gestión de la concurrencia que tenemos, por supuesto intentando bajar lo más posible, para mi estas entradas son también una fuente de aprendizaje. Empezaremos la casa por dónde debemos, o sea que lo primero que haremos será hacer una pequeña inserción de un documento más o menos complejo, ya que esto nos dará juego para alguna cosa interesante, basado en las siguientes clases que podemos ver a continuación:

Actualizaciones

public class Post

    public string Id { get; set; }

    public string Title { get; set; }

    public string Body { get; set; }

    public List<Comment> Comments { get; set; }

public class Comment

    public string UserName { get; set; }

    public string Text { get; set; }

En concreto, la inserción la haremos con los siguientes datos:

using (IDocumentStore store = new DocumentStore() { Url = "http://portblackcode" }.Initialize())

using(IDocumentSession session = store.OpenSession())

    session.Store(new Post()

        Title = "RavenDB(V): actualizaciones, concurrencia y otras hierbas!",

        Body = "En esta quinta entrega de la serie, puede ver las ....",

        Comments = new List<Comment>()

            new Comment()

                UserName = "preguntoncojonero",

                Text = "cualquier pregunta...."

});

    session.SaveChanges();

Bien, llega la hora de empezar a hablar de actualizaciones. Como ya dijimos en la primera introducción a RavenDB, este ha sido creado apoyándose en patrones y experiencias provenientes de ORMs, muy especialmente de NHibernate, aunque algo también hay de otros….Uno de estos patrones recogidos de frameworks como NH o EF es UnitOfWork, el cual a estas alturas seguro que todos conocemos… Por lo tanto si un IDocumentSession es un UnitOfWork entonces la actualización de un documento debería de ser tan facil como lo siguiente:

var post = session.Load<Post>("posts/1");

post.Comments.Add(new Comment()

    UserName ="Unai",

    Text = "Pues efectivamente preguntoncojonero..."

});

session.SaveChanges();

Aunque por ahora seguimos sin hablar de la parte de consulta, fíjese en le método Load, el cual, como seguramente habrá deducido, nos permite obtener un documento en función de su clave, en este caso, estamos utilizando la convención por defecto ( HiLo ). Si miráramos con Fiddler este proceso la primera entrada sería precisamente esta carga:

GET http://ravendbserver/docs/posts/1 HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: portblackcode
Connection: Keep-Alive

Ahora, puesto que cualquier IDocumentSession es un UnitOfWork, cualquier cambio en cualquier objeto consultado, y por lo tanto trackeado por la infraestructura de RavenDB, es llevado al servidor una vez realizada la llamada a SaveChanges, todos los cambios,inserciones,etc de una sesión se hacen en batch para reducir roundtrips.

POST http://ravendbserver/bulk_docs HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: portblackcode
Content-Length: 513
Expect: 100-continue

[{"Key":"posts/1","Method":"PUT","Document":{"Title":"RavenDB(V): actualizaciones, concurrencia y otras hierbas!","Body":"En esta quinta entrega de la serie, puede ver las ....","Comments":[{"UserName":"preguntoncojonero","Text":"cualquier pregunta...."},{"UserName":"Unai","Text":"Pues efectivamente preguntoncojonero..."}]},"Metadata":{"Raven-Entity-Name":"Posts","Raven-Clr-Type":"sampleupdate.Post, sampleupdate","@etag":"00000000-0000-0200-0000-000000000001","Last-Modified":"\/Date(1323811962000+0100)\/"}}]

Fijese en la traza anterior como el cuerpo de nuestro POST contiene la información de la operación a realizar y el nuevo documento a establecer en RavenDB. Esto es una nota muy importante, es decir, es todo el documento que vamos a modificar no es la modificación en si. Esto, por ejemplo, tiene mucho impacto cuando estamos hablando de concurrencia, en concreto de gestión de concurrencia optimista, porque si dos personas incluyen un comentario en un post de forma concurrente podríamos tener problemas. Esto es una de las cosas que quizás mas impacta con respecto a lo que sabemos de modelos relaciones, ¿un problema de concurrencia en una inserción, porque en realidad es lo que estamos haciendo??… Pues si, ahora no hay tablas y filas, hay un documento, una estructura compleja, que cambia, y cambia, en este caso, completamente, por lo tanto, si tenemos dos personas insertando un comentario sino manejamos el problema de concurrencia podríamos perder comentarios….

Concurrencia y ETag

Como podemos solventar el caso anterior, o más bien, como podemos enterarnos de un posible problema de concurrencia??? Bueno, a estas alturas ya todos sabemos que RavenDB es Restfull ¿verdad? y los que sabéis de http sabéis que existe el concepto de ETag para identificar un estado de un recurso en un momento dado. Pues bién, RavenDB utiliza este mismo concepto para gestionar la concurrencia de los documentos. Si volvemos a fijarnos en la trama de actulización veremos como junto con la metadata del documento tenemos una propiedad llamada etag, que en nuestro caso es la siguiente:

"@etag":"00000000-0000-0200-0000-000000000001"

Este valor es automaticamente modificado en el servidor cuando un documento se actualiza, por lo tanto, si tenemos un problema de concurrencia, lo que pasaría es que el etag del documento en el servidor no se correspondería con el documento que nosotros enviamos, seria anterior, y por lo tanto podríamos suponer que estamos intentando actualizar algo que ya ha sido cambiado por otro proceso. Ok, ¿como se activa en RavenDB la comparación de los etag en los procesos de modificación?, pues muy sencillo, cualquier sesión, IDocumentSession, tiene un mecanismo para activar el chequeo de concurrencia de la siguiente forma:

session.Advanced.UseOptimisticConcurrency = true;

Con este simple flag, podemos hacer la indicación de comprobación, en realidad lo que hace es que el documento que se envia incluye otra propiedad ETAG, a mayores de la que hay en metadata, para que el servidor sepa que tiene que hacer esta comprobación. Ahora, si ocurriera un problema de concurrencia, recibiríamos la siguiente respuesta del servidor:

HTTP/1.1 409 Conflict
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
Raven-Server-Build: 531
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 13 Dec 2011 22:49:33 GMT
Content-Length: 219

{
"Url": "/bulk_docs",
"ActualETag": "00000000-0000-0300-0000-00000000000b",
"ExpectedETag": "00000000-0000-0300-0000-00000000000a",
"Error": "PUT attempted on document 'posts/1' using a non current etag"
}

Esta respuesta, provoca que se lance una excepción dentro del API de RavenDB, llamada ConcurrencyException que nos dará la información del problema que tenemos, y por lo tanto, refrescar, si así lo queremos nuestra operación.

Patching….

Bien, seguro que muchos estais pensando que, efectivamente, aunque la gestión de la concurrencia nos permite resolver nuestro problema, lo habitual ante la entrada de un post, es la coincidencia de muchos comentarios y por lo tanto tendremos muchos conflictos y demasiado trabajo para que estamos buscando hacer. Una alternativa para hacer esto es utilizar el concepto del verbo PATH en http. Hacer esto en RavenDB es realmente sencillo, como veremos a continuación, y nos permitirá, en el caso que estamos, crear nuevos comentarios a un post evitando problemas de concurrencia y mejorando el rendimiento ya que nos evitaremos tener que hacer un load de un documento.

Un patch request es, desde un punto de vista de código, tan sencillo como lo siguiente:

var patchRequest = new PatchRequest()

    Type = PatchCommandType.Add,

    Value = RavenJToken.FromObject(new Comment(){User ="Unai",Text = "mira señor pregunton..."}),

    Name = "Comments"

};

Si nos fijamos en el código anterior, un patch está representado por la clase PatchRequest, en la cual, podemos indicar el tipo de cambio a realizar, PatchCommandType nos ofrece comandos como ( Set, UnSet, Add, Modify,Rename …) la propiedad que modificaremos, en nuestro caso Comments y el cambio. En nuestro caso, el cambio es agregar un nuevo comentario, por lo tanto hacemos una transformación del objeto new Comment a Json por medio de la clase RavenJToken.

Una vez creado el request es suficiente con llamar a Patch definido en DatabaseCommands como podemos er a continuación:

using(IDocumentStore store = new DocumentStore(){ConnectionStringName ="Raven"}.Initialize())

using(IDocumentSession session = store.OpenSession())

    var patchRequest = new PatchRequest()

        Type = PatchCommandType.Add,

        Value = RavenJToken.FromObject(new Comment(){User ="Unai",Text = "mira señor pregunton..."}),

        Name = "Comments"

};

    session.Advanced.DatabaseCommands.Patch("posts/1", new PatchRequest[] { patchRequest });

Si prestamos un poco de atención vemos como el método Patch nos permite especificar la clave del documento sobre la que vamos a aplicar el cambio, en este caso posts/1. Si ejecutamos esto, y observamos fiddler veríamos algo similar a lo siguiente:

POST http://ravendbserver/bulk_docs HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: portblackcode
Content-Length: 139
Expect: 100-continue

[{"Key":"posts/1","Method":"PATCH","Patches":[{"Type":"Add","Value":{"User":"Unai","Text":"mira señor pregunton..."},"Name":"Comments"}]}]

y una respuesta de confirmación de cambio:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
Raven-Server-Build: 573
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
Date: Thu, 15 Dec 2011 19:40:37 GMT
Content-Length: 271

[{"Etag":"00000000-0000-0b00-0000-000000000001","Method":"PATCH","Key":"posts/1","Metadata":{"Raven-Entity-Name":"Posts","Raven-Clr-Type":"RavenUpdate.Post, RavenUpdate","Last-Modified":"2011-12-15T18:52:37.8760000Z","Non-Authoritive-Information":false,"@id":"posts/1"}}]

Otras hierbas

Este mismo mecanismo nos puede servir también para realización de un cambio en multiples documentos, para ello tenemos el método Batch en vez de Path, desde aquí os dejo a vosotros la tarea de investigación…

Saludos

Unai

RavenDB (IV) La identidad de los documentos

Unai — Mon, 12 Dec 2011 11:09:00 GMT

En las anteriores entradas hemos trabajado bastante con los documentos, desde una pequeña introducción hasta elementos más avanzados como el trabajo con la metadata y la serialización de los mismos. Sin embargo, hay una cosa sobre la que hemos pasado de puntillas, intencionalmente, pero que trataremos en detalle en esta entrada, y es el tratamiento de la identidad de los documentos. Los documentos, como cualqiuer otro elemento en una colección, tienen que tener un mecanismo que nos permita disitnguirlos de forma unívoca. RavenDB hace un gran aporte en este tema, al dejarnos muchas posiblidades para gestionar las identidades adhoc o delegar en RavenDB, y sus distintos mecanismos, la gestión de la misma.

La propiedad Id

La propiedad Id, sin especificar por ahora el tipo de la misma, juega un papel muy importante dentro de RavenDB ya que por defecto, disponemos de una convención que asocia a esta como la propiedad que marca la identidad de un documento. Por supuesto, estas convenciones pueden modificarse, para ello, solamente tendríamos que especificar los valores de los delegados FindIdentityPropertyNameFromEntityName y FindIdentityProperty.

using (IDocumentStore store = new DocumentStore() { Url = "http://portblackcode" })

    store.Conventions.FindIdentityPropertyNameFromEntityName = e => "Id";

    store.Conventions.FindIdentityProperty = pInfo => pInfo.Name == "Id";

    store.Initialize();

    using (IDocumentSession session = store.OpenSession())

Con la finalidad de ir mostrando las distintas alternativas que tenemos nos basaremos en una estructura de documento similar a la siguiente:

public class Order

    public string Id { get; set; }

    public DateTime OrderDate { get; set; }

    public decimal Total { get; set; }

    public List<OrderDetail> Details { get; set; }

public class OrderDetail

    public int NumberOfItems { get; set; }

    public decimal ItemPrice { get; set; }

Fijese en una cuestión importante que suele escapar a aquellas personas que empiezan a trabajar con documentos y es que la entidad OrderDetail NO tiene identidad. Este forma parte del agregado y por lo tanto no puede vivir fuera de el, llevado a documentos podríamos decir que OrderDetail siempre es parte de un documento Order y por lo tanto la identidad no tiene sentido en el. Note que hablamos de identidad, nada impediría tener algún tipo de secuencia para los detalles de los pedidos.

Sobre una instancia del documento anterior, si procedieramos a su inserción veríamos varios aspectos interesantes que comentaremos a continuación. Supongamos para ello el siguiente código de inserción.

using (IDocumentStore store = new DocumentStore() { Url = "http://portblackcode" })

    store.Conventions.FindIdentityPropertyNameFromEntityName = e => "Id";

    store.Conventions.FindIdentityProperty = pInfo => pInfo.Name == "Id";

    store.Initialize();

    using (IDocumentSession session = store.OpenSession())

        var newOrder = new Order()

            OrderDate = DateTime.UtcNow,

            Total = 1000M,

            Details = new List<OrderDetail>()

                new OrderDetail(){NumberOfItems =1,ItemPrice=20},

                new OrderDetail(){NumberOfItems =1,ItemPrice=20},

};

        session.Store(newOrder);

        session.SaveChanges();

Revisando la secuencia de peticiones con fiddler podemos observar las siguientes trazas, imagen de la derecha, que se corresponden con todo el trabajo necesario para realizar este almacenamiento del documento. La primera de las peticiones, la cual devuelve un 404 es una petición para obtener el valor del HiLo para la colección de Orders. Esto en realidad ya nos ha dicho mucho acerca de como se va a tratar la identidad. RavenDB dispone por defecto de una implementación del algorítmo HiLo que utiliza por defecto cuando disponemos de una propiedad Id. La tercera entrada de la traza se corresponde a la creción del primer valor de este HiLo, vemos el contenido de la traza en la siguientes lineas:

PUT http://XXX/docs/Raven/Hilo/orders
If-Match: 00000000-0000-0000-0000-000000000000
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: XXX
Content-Length: 19
Expect: 100-continue

{
  "Max": 1024
} HTTP/1.1

En la cuarta traza de fiddler ya podemos ver la inserción del documento con una identidad formada por el nombre de la colección y el Lo calculado, en nuestro caso orders/1:

[{"Key":"orders/1","…

Esto está hecho así precisamente para garantizar que las claves sean human readables, como tenemos un API rest el documento anterior podría ser consultado de la siguiente manera:

http://ravendbserver/docs/orders/1

Seguro que no se sorprende si le digo que el algoritmo de HiLo puede ser customizado y/o sustituído por otro si así lo deseamos. La convención DocumentKeyGenerator nos permite realizar esta tarea, como ejemplo demostrativo intentaremos establecer que el mecanismo de generación es el HiLo implementado en RavenDB pero cambiaremos la capacidad para ir de 100 en 100 en vez de 1024 en 1024. Esto, es tan sencillo como se puede ver a continuación:

using (IDocumentStore store = new DocumentStore() { Url = "http://portblackcode" })

    var hiloAlg = new MultiTypeHiLoKeyGenerator(store, capacity: 100);

    store.Conventions.DocumentKeyGenerator = (document) =>

        return hiloAlg.GenerateDocumentKey(store.Conventions, document);

};

         

Bien, hasta ahora entonces podríamos resumir que si una entidad tiene una propiedad Id de tipo string entonces RavenDB se basa en la conbinación del nombre de la colección ( Raven-Entity-Name) y un algoritmo de HiLo para generarnos la identidad de los documentos de una forma sencilla y human readable. Vamos a ver un caso diferente,¿que pasa si la propiedad en vez de ser de tipo string es de tipo int?. Nada, no pasa absolutamente nada, todo sigue igual, se sigue utilizando el mismo mecanismo de Hilo y la identidad es igual que para el caso anterior, aunque nosotros vemos en la entidad este valor como un entero sin el nombre de la colección en vez de como un string.

¿ Y si no quiero un HiLo y quiero un auto incremental?¿ Cómo hago entonces?? Bueno, en realidad esto es también muy sencillo de implementar en RavenDB solamente tendríamos que poner nuestra convención DocumentKeyGenerator como sigue:

using (IDocumentStore store = new DocumentStore() { Url = "http://portblackcode" })

    store.Conventions.DocumentKeyGenerator = (document) =>

        var typeTagName = store.Conventions.GetTypeTagName(document.GetType());

        var separator = store.Conventions.IdentityPartsSeparator;

        return string.Format("{0}{1}", typeTagName, separator);

};

    store.Initialize();

¿Y si ponemos un Guid? En este caso RavenDB nos sigue ayudando y nos ofrece un generador automático para este tipo de propiedades, lógicamente la pega es que ahora este tipo de consultas por rest ya no son tan amigables como teníamos para los casos anteriores.

Por supuesto, otra posibilidad que tenemos es nos especificar ninguna propiedad Id, y delegar por completo en la infraesetructura de RavenDB su generación, por supuesto, esta identidad no será visible en los documentos, por lo menos no directamente tendríamos que usar session.Advanced.GetDocumentId.

Las referencias

Durante todas las entradas hemos estado hablando acerca de como emparejábamos la definición de los documentos con la de agregados. Pues bien, los documentos, al igual que los agregados, pueden contener referencias a otros documentos. En nuestro caso, para ilustrarlo vamos a modificar la definición de nuestra entidad OrderDetail para agregar una referencia a un documento llamada Producto, para ello, incluiremos una propiedad llamada ProductId, fíjese en la convención por defecto.

public class OrderDetail

    public string ProductId { get; set; }

    public int NumberOfItems { get; set; }

    public decimal ItemPrice { get; set; }

Una vez modificado esta entidad, si hacemos el ejercicio de incluir un documento de tipo Producto y referenciamos su identidad dentro de un nuevo pedido podríamos ver como el Raven Management Studio es capaz de reconocer estas referencias y dejarnos navegar por las mismas. Por no adelantarnos no lo haremos, pero en realidad, esto también es relativamente importante para nuestro proceso de consulta puesto que, nos permitirá hacer un eager loading de aquellas referencias que tengamos en nuestros documentos, de tal forma que nos podamos ahorrar round trips con la base de datos y por lo tanto mejorar el rendimiento de nuestro sistema. Curiósamente el método de carga de referencias se llama Include, igual que en Entity Framework para las propiedades de navegación.

Bueno, creo que no nos hemos dejado nada con respecto al tratamiento de las entidades ¿verdad?. En la siguiente entrada sobre RavenDB, veremos un poco, solamente un poco de consultas para tratar los temas de actualización, concurrencia optimista y patches…..

Saludos

Unai

Libro gratuíto y en español de Windows Azure

Unai — Fri, 09 Dec 2011 09:35:18 GMT

Por si a alguno se les ha escapado la noticia permitirme recordaros en mi blog que por fin tenemos el primer libro gratuito y en Castellano sobre Windows Azure y Cloud Clomputing. Aunque tengo el honor de aparecer como autor, por ser fiel a la realidad, os puedo asegurar que mi trabajo, por desgracia, ha sido mínimo y que todo el esfuerzo y los grandes resultados han sido obra de Ibon Landa, Microsoft MVP de Windows Azure.

El libro, accesible en formato digita len Scribid lo tenéis disponible en tres entregas que paso a relatar:

Parte I – Introducción a Windows Azure

Parte II – Sistemas de almacenamiento, SQL Azure y Windows Azure Storage

Parte III – Windows Azure AppFabric

Espero que os guste, por supuesto, los comentarios siempre son bienvenidos…

Saludos

Unai

RavenDB(III) Sobre la metadata y la serialización de los documentos

Unai — Fri, 09 Dec 2011 09:06:00 GMT

En esta tercera de las entradas sobre RavenDB, si lo deseas puedes consultar las entariores aquí y aquí, intentaremos continuar el trabajo dónde lo dejamos, es decir, profundizando acerca del concepto y el trabajo con lo documentos. Como ya hemos podido ver, RavenDB utiliza una serie de convenciones para trasladar nuestros tipos .NET ( incluídos dinámicos y anónimos ) a un payload que enviar por HTTP. Este proceso tiene dos partes importantes, la primera es la de obtención y creación de la metadata y la segunda la obtención del contenido de la entidad que será almacenada como un documento en la base de datos. A lo largo de esta entrada veremos como se realizan ambas tareas y sobre todo como podemos cambiar o ampliar su funcionamiento.

La metadata

En la anterior entrega ya vimos como RavenDB dispone de una serie de convenciones que nos permitían decidir como extrar información de metadata, en concreto, vimos como disponemos de una convención llamada FindTypeTagName gracias a la cual podríamos modificar como se obtenía el valor de Raven-Entity-Name, propiedad de la metadata de un documento por defecto. A mayor de esta propiedad, RavenDB incluye en la metadata la información del tipo .NET que se ha utilizado para serializar el documento en la propiedad Raven-Clr-Type, el valor de esta propiedad en realidad es meramente informativo, es decir, se podría modificar el tipo ( nombre ,namespace etc ) y cargarse perfectamente después aunque el valor de Raven-Clr-Type ya no sea coincidente. Al igual que con Raven-Entity-Name la forma de obtener el tipo de un documento también se puede modificar facilmente, como para el caso anterior, en nuestro DocumentStore.Conventions tendremos el método FindClrTypeName al cual le podremos asignar el delegado que se ejecutará para obtener este valor. Un ejemplo de implementación podría ser el siguiente:

documentStore.Conventions.FindClrTypeName = (type) =>

    return type.FullName;

};

Por supuesto, ver o cambiar las propiedades actuales de la metadata no es lo único que nos puede interesar. Otra tarea importante es la de poder agregar nuevos elementos a esta metadata, bien para realizar alguna extensión de RavenDb, muchos bundles usan esto, o para poder posteriormente hacer algún índice de consulta que use esta información. Agregar información a la metadata de un documento se puede hacer de diferentes formas, iremos viendo estas en los siguientes puntos:

Metadata de forma explícita

Cualquier session de RavenDB pone a nuestra disposición un método para obtener y manipular la metadata de un documento. En concreto, el método GetMetadataFor que tenemos disponible en las operaciones de una sesión nos permite obtener un RavenJObject con esta información. En el siguiente tip de código podemos ver esto:

using (var documentStore = new DocumentStore() { Url = http://localhost }.Initialize())

    using (var session = documentStore.OpenSession())

        var customer = new Customer()

            FirstName = "Unai",

            LastName ="Zorrilla"

};

        var metadata = session.Advanced.GetMetadataFor(customer);

        //TODO: work with this metadata

Estos objetos RavenJObject no son más que, en un principio, pares de clave/valor sobre los que podemos interactuar de una forma sencilla como podemos ver en el siguiente tip de código, en el que incluímos una nueva propiedad de metadata.

using (var session = documentStore.OpenSession())

    var customer = new Customer()

        FirstName = "Unai",

        LastName ="Zorrilla"

};

    session.Store(customer);

    var metadata = session.Advanced.GetMetadataFor(customer);

    metadata["MyCustomMetadataProperty"] = "the customer metadata property value";

    session.SaveChanges();

Por supuesto, si nos vamos a nuestro Raven Management Studio podremos ver como esta nueva propiedad de metadata forma parte de nuestro documento, tal y como nos muestra la imagen anterior.

Metadata con Listeners

RavenDB nos proporciona un mecanismo de listerners similar, en concepto no tanto en propósito, al que tenemos en NHibernate con los event listeners. Para registrar un listener con RavenDB solamente tenemos que hacer uso del método RegisterListener que nos proporciona la clase DocumentStore, ojo que es explícitamente la implementación y no la interface IDocumentStore. Me imagino que esto es intencional para promocionar el registro y la inicialización en un punto, aunque lógicamente esto habría que preguntarselo al creador. Un listener, no es más que cualquier clase que implemente el contrato IDocumentConversionListener. En las siguientes lineas se puede ver la inicialización de un DocumentStore con un Listener y el esqueleto del mismo.

using (var documentStore = new DocumentStore() { Url = "http://portblackcode" }

                            .RegisterListener(new MyDocumentConversionListener())

                            .Initialize())

    using (var session = documentStore.OpenSession())

public class MyDocumentConversionListener

    :IDocumentConversionListener

    public void DocumentToEntity(object entity, Raven.Json.Linq.RavenJObject document, Raven.Json.Linq.RavenJObject metadata)

        throw new NotImplementedException();

    public void EntityToDocument(object entity, Raven.Json.Linq.RavenJObject document, Raven.Json.Linq.RavenJObject metadata)

        throw new NotImplementedException();

Visto esto, si quisiéramos hacer lo mismo que en el caso anterior sería tan simple como lo siguiente:

public class MyDocumentConversionListener

    :IDocumentConversionListener

    public void DocumentToEntity(object entity, RavenJObject document, RavenJObject metadata)

    public void EntityToDocument(object entity, RavenJObject document, RavenJObject metadata)

        metadata["MyCustomMetadataProperty"] = "the customer metadata property value";

La serialización

Bien, llegados hasta aquí ya sabemos como se obtiene la metadata de cada uno de los documentos, a mayores, también sabemos incluso los mecanismos que tenemos para modificar esa metadata si queremos agregar información personalizada y, también, cuales son las convenciones que tenemos por defecto. Ahora llega la hora de entender cuales son los miembros de un tipo que se utilizan para formar los documentos de las entidades y, si es posible, como cambiar este comportamiento. Para hacer este ejercicio vamos a empezar por jugar con una clase que contenga los elementos más habituales en una entidad, propiedades, fields, propiedades de solo lectura, etc etc… la entidad en cuestión es la siguiente:

public class SeralizationEntity

    public string DefaultProperty { get; set; }

    string _readOnlyProperty ="readonly property";

    public string ReadOnlyProperty

get

            return _readOnlyProperty;

    public string _PublicField;

    string _PrivateField ="private field";

    List<string> _Values = new List<string>();

    public IEnumerable<string> Values

get

            return _Values.AsEnumerable();

Si hacemos el ejercicio de guardar una instancia de esta clase en realidad el documento contendría la siguiente información:

["Document":{"_PublicField":null,"DefaultProperty":"default property","ReadOnlyProperty":"readonly property","Values":[]}]

Es decir, RavenDB por defecto solamente incluye los elementos públicos de nuestras entidades, sean propiedades o fields y sean de solo lectura o no las propiedades. Aunque esto está bien, la verdad, es que en muchísimos escenarios no será correcto, necesario o incluso válido. En muchas ocasiones no queremos que algunas propiedades se serializen, como por ejemplo Values, o también que los fields privados sean parte del documento. Por suerte, RavenDB nos ofrece bastantes facilidades para lograr introducir todas nuestras necesidades en cuanto al diseño de los documentos.

La primera parte, la de ocultar alguna propiedad o, incluso, hacer que el nombre de la propiedad en el documento no se corresponda con la propiedad de la entidad puede hacerse fácilmente utilizando una serie de atributos, al igual que, por poner un simil, podemos hacer en MongoDB con BsonDocument, BsonElement etc. En realidad, estos atributos son los definidos por JSON.NET, dependencia de RavenDB para el tema de serialización/deserializacion JSON/.NET. En el siguiente tip de código podemos ver como ignorar la propiedad Values y modificar el nombre de nuestro field publico.

public class SeralizationEntity

    public string DefaultProperty { get; set; }

    string _readOnlyProperty ="readonly property";

    public string ReadOnlyProperty

get

            return _readOnlyProperty;

    [JsonProperty("Field")]

    public string _PublicField;

    string _PrivateField ="private field";

    List<string> _Values = new List<string>();

    [JsonIgnore()]

    public IEnumerable<string> Values

get

            return _Values.AsEnumerable();

Con lo que el documento quedaría de la siguiente forma:

["Document":{"Field":null,"DefaultProperty":"default property","ReadOnlyProperty":"readonly property"}]

Bien, la primera parte ya la hemos tratado, ahora quizás queda en principio la más complicada y es, decirle a RavenDB como tiene que resolver estos contratos de entidad, usar fields privados etc etc…. Por suerto, como siempre hasta ahora, tenemos un punto de trabajo. En RavenDB, la resolución de las entidades, que elementos formarán parte de los documentos se hace por medio de un contrato llamado IContractResolver. La implementación por defecto que RavenDB nos ofrece es DefaultRavenContractResolver y la misma puede agregarse facilmente desde nuestro DocumentStore.

documentStore.Conventions.JsonContractResolver = new DefaultRavenContractResolver(shareCache: true);

Con el fin de lograr nuestro objetivo vamos a hacer una nueva implementación de IContractResolver y, para ahorrarnos tiempo y trabajo la vamos a hacer partiendo de la implementación por defecto,DefaultContractResolver, ojo no es DefaultRavenContractResolver.. Asi, si queremos serializar miembros privados solamente tendríamos que hacer lo siguiente:

public class ContractResolverWithPrivateFieldsSupport

    :DefaultContractResolver

    public ContractResolverWithPrivateFieldsSupport()

        : base(shareCache: true)

        DefaultMembersSearchFlags = BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public;

Bueno, creo que por ahora es bastante, hay que dejar para las siguientes entradas… ¿Preguntas?

Saludos
Unai

RavenDB (II)- Los documentos

Unai — Mon, 05 Dec 2011 10:25:40 GMT

Tal y como ya dijimos en la anterior entrada, RavenDB es una base de datos documental, y esto, está llevado a su extremo. Una de las primeras cosas que me llamaron la atención de RavenDB es que en realidad, físicamente, en RavenDB, no hay otra cosa que documentos, es decir, al contrario que en otros sistemas del mismo tipo como MongoDB, no existen, físicamente por lo menos, el concepto de colecciones, más adelante veremos como en realidad el concepto de colección es lógico es decir, documentos que comparten un atributo de metadata.

Una de las características principales que también nombramos es que Raven es RESTfull y por lo tanto podremos mediante la identificación de recursos y verbos HTTP acceder a los documentos almacenados. Según vayamos avanzando en nuestras entradas iremos viendo los verbos y el contenido de cada tipo de petición. Por ahora, con el fin de ir mostrando distintos ejemplos iremos a nuestro Raven Management Studio y utilizaremos la opción de crear un juego de documentos de ejemplo, tal y como podemos ver en la siguientes figura:

Una vez creados los documentos de ejemplo, podremos observar como RavenDB pone a nuestra disposición un conjunto de recursos principales para almacenar los documentos, estos recursos, o database layout como se conoce en la documentación, son los siguientes:

http://[servidor-raven]/docs : Nos permite acceder a todos los documentos de la base de datos por defecto. Si, raven permite tener múltiples bases de datos, pero, sino hacemos el ejercicio de crearlas siempre tenemos la “Default Database” como punto de trabajo. Si haces esta petición utilizando IE recuerda que este no entiende el application/json y por lo tanto seguramente te pida descargar un archivo (para evitarlo se puede tocar una entrada de registro). Si miramos el resultado de esta petición con Fiddler veríamos algo como lo siguiente:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
Raven-Server-Build: 531
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 01 Dec 2011 18:47:28 GMT
Content-Length: 12447

[{"AlbumArtUrl":"/Content/Images/placeholder.gif","Artist":{"Id":"artists/113","Name":"Os Paralamas Do Sucesso"},"Genre":{"Id":"genres/7","Name":"Latin"},"Price":8.99,"Title":"Arquivo II","CountSold":1,"@metadata":{"Raven-Entity-Name":"Albums","Raven-Clr-Type":"MvcMusicStore.Models.Album, Mvc Music Store","Content-Type":"application/json; charset=utf-8","Last-Modified":"2011-12-01T18:38:30.4410000+01:00","@id":"albums/626","@etag":"00000000-0000-0100-0000-000000000100","Non-Authoritive-Information":false}},{....}]

Fíjese la estructura para el primer documento devuelto, se ha omitido toda la salida por simplicidad, por el servidor, la cual está formada por una serie de propiedades principales, el Id, la metadata, detalles del documento, ultima modificación, un etag etc y la propia información del mismo, el cuerpo o los datos. Más grafícamente, el documento en cuestión seria tal y como se puede ver en las siguientes imagenes extraidas de RavenDB Management Studio.

Si se fija en la imagen de la derecha, dentro de la metadata del documento, tenemos una propiedad llamada Raven-Entity-Name. Es esta propiedad la que nos permite indicar que un documento se categoriza en una determinada colección, en nuestro caso Albums, recuerde que unos párrafos atrás deciamos que físicamente no existe el concepto de colección, aquí tiene la respuesta de cómo hace el Management Studio para categorizarnos esta información.

http://[servidor-raven]/indexes: En este recurso se alamacenarán los documentos referidos a los indices, estáticos o dinámicos, que tengamos en RavenDb. Por ahora no vamos a hablar sobre esto, intentaremoms ir paso a paso y lo tocaremos en su profundidad cuando hablemos sobre consultas.

http://[servidor-raven]/static : Recurso dedicado a los attachements, al igual que los índices lo veremos en cuanto toque.

¿Como se diseña un documento?

Si es la primera vez que usted trabaja con una base de datos documental seguramente empezará pagando el peaje del mundo relacional, una tendencia en la que todos hemos caido la primera vez que nos enfrentamos a esta otra forma de trabajar. Generalmente, el primer error que cometemos es la tendencia a crear documentos como filas de una tabla, es decir elementos planos de datos. Poco a poco, nos damos cuenta que esos documentos pueden contener otros documentos, de hecho deberían. Una buena forma de pensar en estos documentos es igualando los limites del mismo al concepto que tenemos en DDD para definir los agregados, Aggreagte Root, de un modelo de dominio:

“Definition: A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the Aggregate, designated as the root. A set of consistency rules applies within the Aggregate's boundaries.”

De hecho, hay alguna característica importante de RavenDB que hacen que este patrón, Aggregate, sea mucho más sencillo de implementar, mucho más que utilizando ORM’s como EF o NH. Hablaremos un poco más adelante sobre esto.

Por supuesto, un documento puede referenciar a otros documentos, de igual forma que Eric Evans en la anotación sobre Agregados comenta:

“Choose one Entity to be the root of each Aggregate, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to root only”

Cuando veamos el trabajo en la parte cliente nos pararemos, y veremos con detalle, estos puntos que acabamos de comentar, como mantener los invariantes de nuestros agregados y, como se realizan las referencias entre documento y como las mismas son manejadas en RavenDB.

Vale… pero empezamos ya a trabajar!!

Seguro que llegados hasta aquí ya todos tenemos ganas de ponernos con lo nuestro, que es .NET, por lo tanto, empezaremos a ver como que son los documenetos en el mundo .NET y como podemos trabajar con ellos. Lógicamente utilizaremos el API cliente y por lo tanto algunos elementos sobre los que no hemos hablado, aunque mencionaremos su propósito, no se preocupe si no se explican en detalle porque en futuras entradas seguro que se tratan de la forma debida. Por ahora, trabajaremos, por simplificar, con una aplicación de consola a la que le agregaremos las referencias de RavenDB de cliente, recuerde que en los directorios de instalación teníamos una carpeta llamada Client, si trabaja en .NET 3.5 lógicamente debe de usar la carpeta Client3.5.

Ahora que ya tenemos un proyecto con las referencias correspondientes vamos a empezar a crear un ejemplo sencillo. Para RavenDB, un documento no es más que una clase .NET o un tipo dinámico cualquiera, por ejemplo, los siguientes elementos son documentos correctos para RavenDB.

Para empezar a investigar que es lo que se extrae de estos documentos, vamos a escribir la siguientes lineas de código, las cuales, nos permitirán realizar un guardado en la base de datos de estos documentos. Si tiene experiencia con NHibernate, EF seguramente le resulte bastante similar este código al de cualquier guardado con NH/EF. Permitame recordarle que por ahora no nos pararemos demasiado en el código, lo haremos más adelante, permítame ir centrándonos primero en los documentos.

using (var store = new DocumentStore() { Url = "http://localhost" }.Initialize())

    using (var session = store.OpenSession())

        var order = new Order()

            OrderDate = DateTime.Now,

            Address = new ShippingAddress()

                City ="the city",

                ZipCode ="the zip code",

                AddressLine1 ="the address line"

};

        session.Store(order);

        session.SaveChanges();

Si revisáramos con una traza de fiddler el contenido de la petición anterior veríamos algo similar a lo siguiente (en realidad también hay otra serie de operaciones referidas al calculo de la idéntidad de este documento, que serán exáminadas en futuras entradas):

POST http://ravendbserver/bulk_docs HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: portblackcode
Content-Length: 270
Expect: 100-continue

[{"Key":"orders/2049","Method":"PUT","Document":{"OrderDate":"2011-12-05T10:55:03.7964347+01:00","Address":{"City":"the city","ZipCode":"the zip code","AddressLine1":"the address line"}},"Metadata":{"Raven-Entity-Name":"Orders","Raven-Clr-Type":"RavenI.Order, RavenI"}}]

De esto pueden estraerse algunas conclusiones o elementos que deberemos de examinar en más detalle.

Las operaciones de inserción de documentos se hacen sobre un RequestReponder que trabaja en la URI http://ravendbserver/bulk_docs con el verbo POST.
La información de metadata se extrae de la información del tipo que estamos incluyendo, así por ejemplo el nombre de la propiedad Raven-Entity-Name que nos permite calificar a nuestra colección es una pluralización de la entidad. Esta pluralización está marcada por el tipo Raven.Client.Util.Inflector, aunque como todo el RavenDB, podemos modificarla escribiendo nuestra propia convención de pluralización y asignándola como podemos ver a continuación:

store.Conventions.FindTypeTagName = (type) =>

    //this is trivial and not for production implementation

    return type.Name + "s";

};

Al documentose le ha asignado una clave de forma automática “orders/2049” que tendremos que investigar como y que mecanismo se ha utilizado para generarla. Por lo tanto, para consultar este documento podría hacer lo siguiente http://ravendbserver/docs/orders/2049

Si ahora, en vez de utilizar order, utilizamos un tipo anónimo ( igual con lo dinámicos) como el que vimos en las imagenes anteriores tendríamos una payload hacia el servidor como el siguiente:

POST http://ravendbserver/bulk_docs HTTP/1.1
Accept-Encoding: deflate,gzip
Content-Type: application/json; charset=utf-8
Host: portblackcode
Content-Length: 239
Expect: 100-continue

[{"Key":null,"Method":"PUT","Document":{"OrderDate":"2011-12-05T11:17:02.5348622+01:00","Address":"the shipping address"},"Metadata":{"Raven-Clr-Type":"<>f__AnonymousType0`2[[System.DateTime, mscorlib][System.String, mscorlib]], RavenI"}}]

Y de esta información podemos extraer las siguientes conclusiones:

Los documentos representados como un tipo anónimo no son categorizados en ninguna colección.
Por defecto su clave es null y por lo tanto se delega en el servidor la creación de una, RavenDB utiliza un Guid para representar la clave de este documento, así por ejemplo la consulta del mismo se podría hacer de la siguiente forma http://ravendbserver/docs/69851d86-58bf-4915-a6c8-2c9b5ae991f7

Bueno, hasta aquí llegamos con la segunda entrada, en la siguiente, veremos como hace RavenDB para decidir que elementos de una entidad son utilizados como parte de la información de un documento, propiedades publicas o no, fields publicos o no etc etc etc.. a mayores también hablaremos acerca de la identidad y del trabajo con la metadata.

Saludos

Unai

RavenDB (I)–Empezamos….

Unai — Thu, 01 Dec 2011 00:10:00 GMT

Los que tenéis la suerte o desgracia de sufrir mi blog, sabréis lo que me gusta Mongo DB, de hecho, repasando las entradas de mi blog me he dado cuenta de que ya son unas cuantas, sumado esto a los diferentes eventos en los que he tenido la suerte de hablar de esta base documental y, a los proyectos en producción en los que he participado haciendo uso de esta base de datos, os podéis dar una buna idea del aprecio y cariño que le tengo a esta NoSQL.

No obstante, hace ya bastante tiempo que tenía ganas de experimentar, de forma seria, RavenDB, cada vez que podía, restando a las ínfimas horas no ocupadas de las que dispongo, me pasaba por el sitio de esta base de datos y revisaba la documentación, buscando como avanzaba el proyecto y las multiples y diferentes características que se iban añadiendo poco a poco, así como el impacto que el producto estaba teniendo en la comunidad. No voy a negar que en un principio siempre tenía la tentación de buscar comparaciones, sería mentir, puesto que en cierto grado es normal, cuando vas probar un producto, y lo que no es un producto :-), siempre lo comparas con lo que ya conoces. MongoDB hace esto así, entonces, ¿como lo hace Raven DB? … eran de las primeras cosas que venían a la cabeza. Pero, poco a poco, eso se ha ido perdiendo,diluyendo más bien....esto es debido a que, básicamente, creo que sinceramente no hay comparación posible, por lo menos no en el mundo .NET y menos aún en ciertos escenarios, por lo tanto, en esta entrada y en las siguientes de la serie no vais a encontrar comparaciones, si acaso ligeras referencias de términos o elementos que hacen a RavenDB diferente.

Lógicamente lo primero es lo primero, en esta entrada empezaremos por los conceptos más básicos, sitio del producto, descarga y puesta en marcha etc.., según avancemos en las diferentes entradas iremos ampliando la información y nos meteremos en harina, que es dónde nos gusta estar:

RavenDB .NET

El sitio principal del proyecto es www.ravendb.net , por ahora, es un sitio aún no demasiado bien cuidado, pero están preparando un nuevo portal mucho mejor organizado, con mejor presencia y sobre todo mucho más contenido que el actual, este nuevo portal se puede consultar en http://beta.ravendb.net . Nada más entrar al sitio podemos ver las principales características de RavenDB:

Base de datos documental
Transaccional
RestFull
Scalable
Schema Free
Multi-Level caching
Extensible

Para serle sincero, desde el principio fue una sorpresa ver como en este sitio, y más aún en el beta, hay una gran cantidad de documentación, tutoriales, FAQ,etc etc que podemos consultar,y, si aún tenemos preguntas no respondidas podriamos ir al propio grupo de soporte para RavenDb.

Despliegue

Una vez que hemos descargado una build de RavenDB, podéis acceder a las fuentes y últimos binarios aquí, simplemente tenemos que descomprimir el contenido de la descarga y nos encontraremos con una estructura de directorios similar a la que podéis ver en la imagen presente a la izquierda. En cada uno de los directorios podemos encontrar diferentes elementos, la información completa de su contenido la teneis disponible en el correspondiente fichero readme.txt. Por ahora solamente nos vamos a fijar en las carpetas Server y Web que son las que nos permitirán desplegar un servidor de Raven DB, de varias formas diferentes.

Para el primer ejemplo de despliegue nos iremos a la carpeta Server, en esta carpeta encontraremos, a mayores del conjunto de librerías necesarias, un ejecutable llamado Raven.Server.exe . Este ejecutable representa un servidor de Raven, el cual podría ser levantado simplemente con la ejecución de la siguiente linea de comandos:

Raven.Server.exe –debug --browser

Es recomandable ver la ayuda de la linea de comandos para ver las diferentes opciones que tenemos disponibles. En este sentido me ha recordado mucho a MongoDB, el proceso es similar a levantar un mongod en MongoDB y, además, comparte tambien con esta bd la opción --install para poner Raven DB como un Servicio Windows.

El fichero de configuración del proceso Raven.Server.exe.config contiene algunos parámetros de configuración importantes, aunque no todos como veremos durante las siguientes entradas.

Como se habrá dado cuenta con estos tres parámetros podemos configurar el puerto en el que escuchará el HttpListener asociado a RavenDB, la carpeta que se utilizará para almacenar toda la información referida al servidor de Raven ( datos, indices etc…) y los permisos que por defecto tendrá un usuario anónimo, estando este por defecto a Get.

Si no queremos hacer el despliegue de Raven como un Servicio Windows, podemos optar por un despliegue de un sitio en Internet Information Server. Para ello tenemos el directorio Web, el cual, si se fija lo único que contiene es, además del directorio bin con las dependencias necesarias, el archivo de configuración del sitio con un handler para especificar el manejo de los request, en concreo la factoria de los RequestResponders, algo sobre lo que hablaremos cuando veamos la parte de extensibilidad, simple ¿verdad?

    <system.webServer>
        <handlers>
            <add name="All" path="*" verb="*"
                        type="Raven.Web.ForwardToRavenRespondersFactory, Raven.Web"/>
        </handlers>
    </system.webServer>

Raven Db Management Studio

Tanto si levantamos el servidor como una consola, un servicio windows o un sitio de IIS en todos tendremos disponible una aplicación Silverlight, si, has oído bien, llamada Raven Db Management Studio que, como su propio nombre indica, es una pequeña herramienta de administración de las diferentes bases de datos que tengamos en el servidor.

Por ahora no vamos a entrar en más consideraciones, aún hay muchas cosas que explicar, según avancemos en las diferentes entradas iremos viendo esta herramienta y el porque de algunas cosas. Por ahora, con tener el servidor levantado y preparado para funcionar es suficiente.

Un detalle importante, que a mi no me ha resultado demasiado sencillo encontrar en la documentación es que el sitio de IIS tiene que tener habilitada la integración con Windows. Recurede que en la settings de configuración se podía restringir el acceso anónimo por lo tanto, sino queremos trabajar en modo anónimo tenemos que asegurarnos que cumplimos esto.

Bueno, por ahora lo dejaremos aquí, seguiremos en las siguientes entradas, que no se retrasarán mucho, lo prometo.

Saludos

Unai

EF Migrations, EF 4.3 y que nos deparará el futuro

Unai — Wed, 30 Nov 2011 17:50:00 GMT

Hoy mismo se ha hecho pública la primera beta del paquete de “migraciones” que el equipo de Entity Framework ha estado preparando durante ya hace algún tiempo, de hecho, en este mismo blog ya hemos publicado unas cuantras entradas,aquí y aquí, referidas a su funcionamiento. Lo más destacable de este anuncio, a mayores de los cambios y novedades en el paquete, comentaremos sobre esto más adelante, es el hecho de que incorporarán Migrations como parte de EF 4.3, es decir, que ya no existirá el paquete EntityFramework.Migrations como tal. Desde mi punto de vista, esto es sin duda una gran idea, puesto que el trabajo con migraciones no es “algo opcional” en un proyecto real. Hablando con un miembro del equipo sobre cuales serían las implicaciones directas de este paso se puso sobre la mesa la posibilidad de que alguna funcionalidad estuviera duplicada entre el code base de EF Code First y el paquete de migraciones. Un ejemplo de esto, podría ser por ejemplo los inicializadores de EF, IDatabaseInitializer<T> cuya funcionalidad podría solaparse con el Seed que podemos hacer en nuestro DbMigrationsConfiguration, aunque en mi opinión ambos podrian tener propósitos diferentes. Lo más interesante de este movimiento, es lo que se puede leer por detrás, es decir, como poco a poco el equipo de EF está haciendo movimientos para apartarse de la dependencia de .NET Framework, dependencia que seguro que afecta enormemente a su ciclo de vida, a su capacidad de entrega y a la resolución de problema de una forma más agil. Seguro, que no dentro de mucho, nos darán alguna sorpresa en cuanto al ciclo de vida y modelo de desarrollo con respecto a EF.

Bueno, al chollo:

Realmente, el funcionamiento de esta beta es bastantet similar, de hecho ya advierte de que hay unas pequeñas features y sobre todo refactoring. Lo primero en lo que nos podemos fijar con respecto a las versiones anteriores es que ahora la clase DbMigrationContext de las versiones anteriores se sustituye por DbMigrationsConfiguration:

    internal sealed class Configuration : DbMigrationsConfiguration<BlogUnitOfWork>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
        
            // Seed data: 
            //   Override the Seed method in this class to add seed data.
            //    - The Seed method will be called after migrating to the latest version.
            //    - You can use the DbContext.AddOrUpdate() helper extension method to avoid creating
            //      duplicate seed data. E.g.
            //
            //          myContext.AddOrUpdate(c => c.FullName,
            //              new Customer { FullName = "Andrew Peters", CustomerNumber = 123 },
            //              new Customer { FullName = "Brice Lambson", CustomerNumber = 456 },
            //              new Customer { FullName = "Rowan Miller", CustomerNumber = 789 }
            //          );
            //
        }
    }

Por supuesto, aunque ahora no se muestren, esta clase nos sigue ofreciendo la posibilidad de establecer las generadores de código SQL y codigo C# de las migraciones que hagamos, además de otra serie de flags, como por ejemplo AutomaticMigrationDataLossAlowed, que nos permitirán modificar algún comportamiento adicional. Otro elemento a mayores, es ver como han creado un nuevo método extensor, AddOrUpdate que nos simplificará el Seed de los datos.

    public partial class InitalSteep : DbMigration
    {
        public override void Up()
        {
            CreateTable(
                "Blogs",
                c => new
                    {
                        Id = c.Int(nullable: false, identity: true),
                        Title = c.String(),
                        Description = c.String(),
                        AuthorId = c.Int(nullable: false),
                    })
                .PrimaryKey(t => t.Id)
                .ForeignKey("Authors", t => t.AuthorId, cascadeDelete: true)
                .Index(t => t.AuthorId);
            
            CreateTable(
                "Authors",
                c => new
                    {
                        Id = c.Int(nullable: false, identity: true),
                        FirstName = c.String(),
                        LastName = c.String(),
                    })
                .PrimaryKey(t => t.Id);
            
        }
        
        public override void Down()
        {
            DropIndex("Blogs", new[] { "AuthorId" });
            DropForeignKey("Blogs", "AuthorId", "Authors", "Id");
            DropTable("Authors");
            DropTable("Blogs");
        }
    }

Al igual que hacíamos antes, también podemos hacer customizaciones en las distintas migraciones, así, por ejemplo, si nos interesará poder un índice sobre la columna FirstName de nuestra tabla authors podríamos hacer alog como lo siguiente:

           CreateTable(
                "Authors",
                c => new
                    {
                        Id = c.Int(nullable: false, identity: true),
                        FirstName = c.String(),
                        LastName = c.String(),
                    })
                .PrimaryKey(t => t.Id)
                .Index(a=>a.FirstName,true);

A mayores de los métodos de customización de DbMigration, base para todas las definiciones de migración, esta nos ofrece un método llamado Sql que nos servirá para ejecutar, en el caso de necesitarlo, un comando SQL, como por ejemplo un UPDATE para poner un valor por defecto a una de las nuevas columnas, etc.

Bueno, aquí se queda esto por ahora… Para los que os guste el tema y aún no hayais podido profundizar os recomienod los recomiendo las guias paso a paso del equipo de Entity Framework que están aquí y aquí.

Nos despedimos hasta la próxima dónde empezaremos una serie sobre RavenDB.

Un saludo

Unai

HOT:Inserciones masivas en Sql Sersver vs Mongo DB ( III)

Unai — Sun, 20 Nov 2011 13:26:51 GMT

DESCARGO DE RESPONSABILIDAD

Antes de empezar la entrada me gustaría dejar claro que esto es un pasatiempos, una forma de dilucidar quien pagaba las cenas durante el tiempo que nos toco a los dos estar perdidos en una ciudad que no es la nuestra con nuestros respectivos trabajos. La idea de esta serie de blogs no es ver si queremos más a Papa o a Mama, a Sql Server o a una NoSQL. Los resultados que se obtengan no tienen porque hacer pensar que una es mejor que la otra ( sobre todo cuando son compatibles) y por supuesto el performance no es una(la única) razón de selección de una NoSQL como Mongo, escalabilidad, schema-free, base, last-update ni de un sistema transacciónl como Sql Serve. Si esto te queda claro y quieres jugar con nosotros, y por supuesto, aprender como lo hemos hecho nosotros, a forzar situaciones como la presente tanto de Sql Server como de Mongo entonces sigue leyendo…

La bala de la recamara….

Me voy a permitir adelantarme al post de Pablo Doval con sus conclusiones puesto que, este finde esta muy, pero que muy ocupado haciendo que el Sql Server de otro ande más rapido. Como había dicho, me preocupaba mucho el tema de mis bloqueos, puesto que o cambiaba de tercio o no tendría mucho margen de mejora. Pensando y pensando (algún comodín también) me puse a ver que podría hacer y recorde que con las Capped Collections de Mongo DB podría ganar algo, puesto que a la hora de crearlas podría especificar el espacio a ocupar y por lo tanto hacer un pequeño prefetch de la base de datos. En realidad, una colección capped no es más que una colección con un tamaño máximo dado y un número de documentos máximo. La definición exacta de las capped collections la tenéis en la siguiente frase:

Capped collections are fixed sized collections that have a very high performance auto-FIFO age-out feature (age out is based on insertion order). They are a bit like the "RRD" concept if you are familiar with thatç

Bueno, “high performance auto-FIFO”…. esto es lo que andaba buscando…. Vamos, además, a unirlo con un poco de paralelismo para ver si nos sorprendemos con los resultados que obtengamos. Para ello, lo primero que haremos será levantar nuestro servidor de mongodb con prácticamente las mismas opciones que en la entrada anterior, he incluido alguna más pero no han tenido demasiado efecto…

mongod -- dbpath c:\mongo\data

-- nohttpinterface

-- noauth

-- nojournal

-- quiet

-- verbose

-- diaglog

-- logpath log.txt

-- install

Ahora, modificaremos nuestro código para que se cree la colección a utilizar como una capped collection, fíjese que en esta creación hemos puesto ya tamaños máximos de documentos y espacio. Además también hemos realizado otra optimización al poner SetAutoIndex a false eliminando así la creación del índice sobre _id por defecto.

        static MongoCollection SetupAndPrepareCollection()
        {
            var dbSettings = new MongoServerSettings()
            {
                ConnectionMode = ConnectionMode.Direct,
                SafeMode  = SafeMode.False,
                Server = new MongoServerAddress("localhost")
            };

            //create server and get database
            var server = MongoServer.Create(dbSettings);
            var db = server.GetDatabase("speedUp");

            //set collection options
            var collectionOptionsBuilder = new CollectionOptionsBuilder();
            collectionOptionsBuilder.SetAutoIndexId(false);
            collectionOptionsBuilder.SetCapped(true);
            collectionOptionsBuilder.SetMaxSize(40000000);
            collectionOptionsBuilder.SetMaxDocuments(590000);

            string collectionName = "tests";

            if (db.CollectionExists(collectionName))
                db.DropCollection(collectionName);

            db.CreateCollection(collectionName, collectionOptionsBuilder);
            db.SetProfilingLevel(ProfilingLevel.None);

            return db.GetCollection(collectionName);
        }

El paralelismo es sencillo, basta con usar el magnífico API de TPL y agregar unas cuantas Task como se ve a continuación. Como seguramente muchos os preguntéis, he probado diferente número de hilos, y la verdad es que no he obtenido mejor, lo cual, me hace indicar que el problema no es de contención en el procesador, ni de uso, es ya un tema en MongoDB.

            var watch = Stopwatch.StartNew();

            var task = new TaskFactory().StartNew(()=>
            {
                new Task(() => Work(), TaskCreationOptions.AttachedToParent).Start();
                new Task(() => Work(), TaskCreationOptions.AttachedToParent).Start();
                new Task(() => Work(), TaskCreationOptions.AttachedToParent).Start();
                new Task(() => Work(), TaskCreationOptions.AttachedToParent).Start();
                
            });
            task.ContinueWith(t=>
            {
                watch.Stop();
                Console.WriteLine(watch.Elapsed);
            },TaskContinuationOptions.OnlyOnRanToCompletion);

El código de Work es el siguiente :

        static void Work()
        {
            //create batch and iterations specs
            int maxDocuments = 125000;
            int batchSize = 100;
            int iterations = maxDocuments / batchSize;

            int index = 0;
            var batch = new BsonDocument[batchSize];

            //create insert options
            var insertOptions = new MongoInsertOptions(collection);
            insertOptions.CheckElementNames = false;
            insertOptions.SafeMode = SafeMode.False;
            insertOptions.Flags = InsertFlags.ContinueOnError;

            for (int i = 0; i < iterations; i++)
            {

                while (index < batchSize)
                {
                    batch[index] = new BsonDocument()
                    {
                        {"_id",Guid.NewGuid().ToByteArray()},
                        {"s","XXXXXXXXXXXXXXXXXXXX"}
                    };
                    ++index;
                }

                index = 0;
                collection.InsertBatch(batch, insertOptions);
            }
        }

Venga, vamos a hacer la prueba…. [redoble de tambores…….] el resultado es …. 1,6 segundos, gracias a las capped collections y al prefetch del tamaño y número de documentos he aumentado el rendimiento enormemente, de 3,5 a 1,6 segundos en insertar 500K documentos…

…….Sigo preocupado…..

Las malas lenguas me han dicho que pablo bajará ese tiempo…. y ya, lo único que se me ocurre es montar un sharding y no tengo muy claro que eso NO sea hacer TRAMPAS….

Nos leemos,

Unai

HOT:Inserciones Masivas en MongoDB vs Sql Server (II)

Unai — Fri, 18 Nov 2011 10:36:13 GMT

DESCARGO DE RESPONSABILIDAD

Bueno, seguro que muchos habéis leido la entrarada de mi compañero de batallas y amigo Pablo Doval sobre un pequeño pique “paga cenas” a ver quien insertaba de una forma más rápida 500 K de registros. En la primera entrada de mi contrincante hemos podido ver como su primer esfuerzo ha resultado en 4 segundos escasos, quiero imaginarme que con escasos no se refiere a 0,9 por lo que entenderé que mi primer reto es superar simplemente 4 segundos. Bien, 4 segundos, no está nada mal, sobre todo porque teniendo en cuenta lo que ha utilizado me temo que tiene un gran arco de mejora ( aunque no seré yo quien se lo diga, más que nada porque de Sql Server el ya sabe mejor que yo …). Vamos a ver que podemos hacer con nuestro jueguete, por supuesto, no empezaremos haciendo ninguna optimización, lo más simple, así tendremos una ligera idea de por dónde andamos.

El primer intento

Tal y como acabo de comentar el primer intento será lo mas simple posible, insertaremos en MongoDB 500K documentos. Si, documentos, para los que no lo sepais, MongoDb es una base de datos documental, entendiendo como esto a algo similar a lo que podéis ver en la imagen de la derecha. Las normas de nuestra pequeña apuestas decían que teníamos que insertar 500K documentos ( el filas ) con un tipo de datos Guid y una cadena con 20 caracteres. Por lo tanto, abriremos un proyecto de Visual Studio 2010 y vamos a empezar a jugar. Lo primero será agregar las librerías necesarias para trabajar con Mongo DB, para ello podemis ir hacia la sección de drivers de Mongo DB y descargar los de C# o mejor aún utilizar el paquete de NuGet que esta gente tiene disponible, concretamente el paquete se llama mongocsharpdriver.

Levantando el servidor

Lógicamente, antes de conectarnos tenemos que levantar un servidor de MongoDB, para ello, por ahora, no utilizaremos ninguna setting especial, de hecho, lo levantaremos como una consola y no como un servicio de Windows ( si, ya se que eso puede tener un impacto, veremos si es cierto… ). Es decir, levantaremos el servidor con las simples instrucciones siguientes:

mongod.exe –dbpath c:\mongo\data [c:\mongo\data es el path para alojar la base de datos]

Ahora, es hora del código, con las siguientes lineas voy a acceder a una colección llamada tests en una base de datos llamada apuesta dónde posteriormente intentaré introducir los 500 K registros.

        static MongoCollection GetCollection()
        {
            var server = MongoServer.Create("mongodb://localhost");
            var database = server.GetDatabase("apuesta");

            return database.GetCollection("tests");
        }

Ahora, solamente me queda darle a mi bucle y esperar los resultados para ver desde dónde vamos a empezar a jugar, espero sinceramente que no sea muy alto porque 4 segundos es un muy buen número. Mientras me preparaba para hacerlo me puse a pensar si lo haríamos de forma tipada o no. Es decir, el API de MongoDB me permite definir los distintos documentos mediante clases que posteriormente el serializará al formato de trabajo. Aunque no quería hacer ninguna optimización temprana me parecía que esto sería un poco estúpido y por lo tanto trabajaría directamente con documentos no tipados, es decir, con BsonDocuments.

        static void Main(string[] args)
        {
            var collection = GetCollection();

            var watch = Stopwatch.StartNew();

            for (int i = 0; i < 500000; i++)
            {
                collection.Insert(new BsonDocument()
                {
                    {"Guid",Guid.NewGuid()},
                    {"Data","XXXXXXXXXXXXXXXXXXX"}
                });
            }

            watch.Stop();
            Console.WriteLine(watch.Elapsed);
            Console.ReadLine();
            
        }

……………………. ( redoble de tambores)… 18,74 segundazos…… bufff, más de 4 veces que el mejor número de Pablo. Lo primero que hago es comprobar que no he comentido un error, que todos los datos estan en la base de datos, por lo que me conecto a mongo y hago una revisión del numero de documentos y del formato que contienen, en la siguiente imagen podéis ver los pasos que he seguido desde la shell de MongoDb para hacerlo.

….. unos ínfimos cambios y otro disparo….

Bien, estamos lejos, pero la verdad, teniendo en cuenta como lo hicimos, tampoco es que me asustará demasiado, hay dos cosas que podemos arreglar rápidamente, la primera es que cuando levantamos el servidor de Mongo como consola no desabilitamos el stdout ni el nivel de verbosidad, por lo tanto, segurmanente eso esté influyendo bastante. La segunda es que mongo dispone de un sistema de batching por el cual podemos insertar un conjunto de documentos de forma simultanea.

Empezaremos los cambios por levantar una instancia del servidor de mongo como un servicio de windows con la siguiente parametrización:

mongod –-install [lo instalamos como un servicio]

--diaglog 0 [deshabilitamos los diagnostics log]

--quiet [reducimos la verbosidad de standard out

--nojournal [ eliminamos la feature introducida en 1.8 para asegurar recuperación de datos no insertados en caso de crash]

Ahora, le toca la parte al código, vamos a hacer el batching, para ello, modificamos nuestro código de inserción por el siguiente:

        static void Batching()
        {
            var collection = GetCollection();

            int max = 500000;
            int batch = 1000;
            int iterations = max / batch;

            int count = 0;
            var watch = Stopwatch.StartNew();
            for (int i = 0; i < iterations; i++)
            {
                var data = new BsonDocument[batch];
                while (count < batch)
                {
                    
                    data[count] = new BsonDocument()
                    {
                        {"g",Guid.NewGuid()},
                        {"d","XXXXXXXXXXXXXXXXXXX"}
                    };

                    ++count;
                }

                collection.InsertBatch(data);
                count = 0;
            }

            watch.Stop();
            Console.WriteLine(watch.Elapsed);
            Console.ReadLine();

        }

Ahora tomamos el tiempo y es ….5.005 segundos…. nada mal, si señor, estamos cerca ya de nuestro amigo…. pero aún falta ganar un segundo por algun lado. La primera parece pensar en jugar con los tamaños del batch pero después de algunas pruebas la mejora no es substancial como para ponerla, en mi máquina mi mejor respuesta es con un tamaño de 600 y a partir de 1500 los tiempos se hacen muy grandes. Por lo que parece que se mueve mejor con batch pequeños de estos documentos que muy grandes…

…tercer disparo y Pablo paga la cena (hoy)

Hay que ganar un segundo, ese es el reto ahora. Como lo hacemos?? bueno, a ver, vamos a revisar las opciones de inserción para ver si podemos tunear algun parámetro. Si, nos fijamos en las sobrecargas de InsertBatch, veremos que podemos incluir unas opciones de insercion por medio de la clase MongoInsertOptions. Si revisais esta clase, veréis que hay tres parámetros importantes, CheckElementNames,SafeMode y Flags. El primero, nos permite decidir si queremos comprobar los nombres de los documentos, claves, collecciones etc antes de procesar un insert, el segundo permite especificarnos el modo de seguridad por defecto y el tercero el comportamiento en caso de fallo. Vamos a tunear estas opciones con nuestros batch y a ver que resultado tenemos….

            var insertOptions = new MongoInsertOptions(collection);
            insertOptions.CheckElementNames = false;
            insertOptions.SafeMode = SafeMode.False;
            insertOptions.Flags = InsertFlags.ContinueOnError;

…youhuuuuu 3.50 segundos… Pabloooooooooooooooooooooooooooooooo pagas la cena!!!!!!!!!!!!!!!!!

…aún así, sigo preocupado

Si, sigo preocupado porque Pablo tiene buenas posibilidades de mejora y yo, viendo las estadisticas de mi Mongo, siguiente imagen, veo que si quiero bajar de esos tiempos tengo que cambiar algún concepto y usar algo más de artillería… pero no se si me llegará…. en fin, ya veremos si supera los 3.50 y por cuanto lo supera…

Nos veremos en la siguiente…

Unai

DDD-CQRS post event

Unai — Fri, 11 Nov 2011 10:55:04 GMT

Bueno, tras una semana dura el evento de IASA sobre DDD y CQRS que he tenido la suerte de co-organizar junto a Cesar de la torre y el resto de miembros fundadores de IASA, llega el momento de hacer un pequeño recopilatorio. La verdad, pensar al principio en tener a Eric Evans, Udi Dahan y Diego Vega ( EF Team ) en un evento gratuito abierto a todas las tecnologías era algo que nos parecía muy, pero muy complicado, por momentos imposible. Al final, gracias a los distintos patrocinadores el evento se pudo producir y disfrutamos de magníficas sesiones, por supuesto incluyo aquí al resto de participantes ( alfredo casado, jorge serrano etc.. y un servidor :-)).

Además de todas estas charlas gratuitas, también teníamos dos dias de trabajo completos con Eric Evas y Udi Dahan, unos cursos por un precio más que razonable, yo diría que casi hasta regalado, que han tenido un gran aceptación y practicamente llenarons las plazas disponibles. Se, por mi propia experiencia y porque he podido hablar y conocer a muchos de los asistentes, que los cursos han sido muy bien aceptados y que todos repetiríamos….

Os dejo una pequeña foto con Eric Evans, Udi Dahan, Diego Vega, Pierre, Javier Calvarro y Cesar de la Torre y un servidor

Espero que esto lo podamos volver a repetir en IASA Spain.

Unai

Intellitrace como tu sistema de rastreo

Unai — Wed, 12 Oct 2011 11:53:16 GMT

Hace ya un pequeño tiempo, observé desde la distancia una “discusión” acerca de las implementaciones de logging y tracing en nuestras aplicaciones. Lógicamente, muchos de los argumentos de este tipo de discusiones ya son más que de sobra conocidos, unos tiran por AOP otros les gusta la intercepción etc, etc.. Mi compañero Rodrigo, metido en esa conversación intentó primero hacer una diferenciación entre lo que realmente es logging, como información del proceso, y las trazas como información de rastreo únicamente válida para nosotros como desarrolladores. Después de este pequeño, pero importante inciso, alegó que pensar hoy en dia en “inventar” el sistema de trazas caía un poco dentro de “Reinventent the wheel” puesto que si trabajábamos en Visual Studio 2010 teníamos algo llamado Intellitrace.

Seguramente muchos conoceis intellitrace de vuestros procesos de depuración con VS, sin embargo, también es posible utilizar Intellitrace fuera de visual studio y llevarlo por ejemplo a un entorno de producción para hacer una sesión de depuración en caso de necesitarlo. A lo largo de la siguiente entrada veremos los pasos necesarios para realizar esta tarea, y como, gracias a Intellitrace, nuestras posibilidades en cuanto a las trazas se verán incrementadas enormemente:

Requisitos

Lo primero siempre es lo que necesitamos, y en este caso, los requisitos necesarios para correr intellitrace viene marcados por una serie de archivos que tendremos que llevar a nuestro entorno, es importante notar que no requiere instalación tradicional ninguna.

Intellitrace.exe, %ProgramFiles%\Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools.

Intellitrace.exe.config, %ProgramFiles%\Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools.

TraceLogProfiler.dll, %ProgramFiles%\Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools.

Microsoft.VisualStudio.Intellitrace.dll %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies.

CollectionPlan.xml,%ProgramFiles%\Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools.

Puesta en marcha

Una vez que hemos llevado estos requisitos hasta nuestro entorno, veremos como ejecutar intelligrace para un proceso, en mi caso, para el ejemplo he creado una pequeña aplicación de consola que trabaja con una base de datos, escribe un fichero, y accede a registro. La idea, es poder observar todo este trabajo desde el resultado de la ejecución de intellitrace.

Levantaremos una linea de comandos y ejecutaremos algo como lo siguiente:

Intellitrace.exe launch cp:/CollectionPlan.xml /f:Out.itrace “path\sample.exe”

Si se fija, los dos parámetros importantes de esta llamada son cp:/CollectionPlain y /f:Out.xml. CollectionPlan.xml nos permite especificar que es lo que queremos recopilar en nuestra sesión de trazas, es decir, la información que deseamos ver. El segundo parámetro, por otro lado, nos permite establecer el fichero de salida, el cual después llevaremos hasta un entorno con Visual Studio sobre el que podamos ver y analizar los resultados. Antes de empezar la ejecución, abriremos nuestro fichero de collectionplan.xml, buscaremos el elemento TraceInstrumentation y estableceremos el atributo enabled a true.

<TraceInstrumentation enabled="true">

Análisis de resultados

Bien, una vez que ya hemos ejecutado Intellitrace y obtenido el fichero de resultado ( nuestro *.iTrace) lo llevaremos hasta un equipo con Visual Studio, en este podremos ver algo similar a lo siguiente:

Realmente, aquí ya es similar a como si estuviésemos en una sesión de Visual Studio normal, podéis probar a ver los eventos de intellitrace, las llamadas a métodos, rebobinar etc etc….

Queremos más

La información de llamadas a métodos, variables, hilos o módulos cargados no siempre es suficiente. Gracias a nuestro archivo CollectionPlan.xml podemos ir configurando la información que deseamos incluir en nuestros ficheros de Intellitrace. Algunos eventos importantes son acceso a disco, ADO.NET, uso de registro etc etc… A continuación se puede ver la interacción con ADO.NET de nuestra pequeña aplicación de ejemplo.

Ojo con el licenciamiento

En principio el uso de Intellitrace en producción es algo que se escapa a la licencia de Intellitrace, aunque es algo que no tengo tan claro si es solamente al soporte o una prohibición por algún motivo. Hay un post aquí dónde tocan este tema y se pueden extrar algunas conclusiones.

´Más información

Sobre la linea de comando de intellitrace hay mucha información repartida en la web, para aquellos que deseais saber más os recomiendo empezar con algunos enlaces que os ayudarán en las primeras dudas:

http://blogs.msdn.com/b/ianhu/archive/2009/11/16/intellitrace-itrace-files.aspx

//especialmente interesante si quieres hacer intellitrace de algo que no sea un .exe, por ejemplo IIS, un servicio de windows, etc..

http://blogs.msdn.com/b/msaffer/archive/2010/12/07/using-intellitrace-outside-the-ide.aspx

http://blogs.msdn.com/b/ianhu/archive/2010/05/25/intellitrace-links.aspx

Espero que esto os resulte de interes

Saludos

Unai

ASP.NET MVC + WIF

Unai — Thu, 06 Oct 2011 03:55:38 GMT

Últimamente tengo poco tiempo para postear, mucho menos de lo que debería seguramente, y entre tarera y tarea a veces surgen temas como el que voy a contaros que quizás sean de ayuda para otras personas, eso espero por lo menos. En casi toda la documentación y ejemplos de WIF se tocan los RP pasivos con clientes de ASP.NET tradicional. Si bien, seguramente aún hoy por hoy estos serán mayoría en los desarrollos actuales, seguro que, muchos estaréis pensando empezar vuestros proyectos en ASP.NET MVC e intentar integrar Windows Identity Foundation para delegar todo el trabajo de autenticación. A continuación intentaré mostraros los pasos necesarios para realizar esta tarea y aquellos detalles que debéis de tener en cuenta.

Lo primero que haremos será partir de una aplicación MVC, cualquiera de los tipos de aplicación vale(internet,intranet,empty), una vez hecho esto, procederemos a agregar la referencia al STS con el que queremos trabajar. Como hemos hecho otras veces, esto lo realizaremos con la integración de las tools de WIF en Visual Studio, gracias a las cuales en los menus contextuales de nuestros proyectos web tendremos la entrada “ Add STS Reference” ( si no has visto nada de WIF, te recomiendo las entradas siguientes ( 3-1 y 3-2) antes de seguir)

Seguiremos el asistente de WIF como hasta ahora hemos hecho en todos los ejemplos, en nuestro caso, creando un nuevo STS y adjuntándolo a la solución, imagen siguiente:

Una vez completado el asistente podremos ver como en nuestra solución se ha incluído el nuevo proyecto del STS y además, se ha modificado “notablemente” el archivo de configuración de nuestro cliente MVC. Intentareamos ir desgranando todo lo que ha pasado con este asistente poco a poco:

Modificación del web.config del cliente mvc

Una vez terminado el asistente, FedUtil.exe, nuestro web.config ha cambiado en unos cuantos puntos para agregar aquellos elementos necesarios para trabajr con WIF. En primer lugar, se ha incluído una nueva sección de configuración, llamada Microsoft.IdentityModel tal y como podemos ver a continuación:

 <configSections>
    <section name="microsoft.identityModel" 
             type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </configSections>

Esta sección de configuración, nos permite establecer la configuración necesaria para trabajar con wif, por defecto la que vemos a continuación:

<microsoft.identityModel>
<service>
    <audienceUris>
      <add value="http://localhost:1477/" />
    </audienceUris>
    <federatedAuthentication>
      <wsFederation passiveRedirectEnabled="true" issuer="http://localhost:2511/MVCRP_STS/" realm="http://localhost:1477/" requireHttps="false" />
      <cookieHandler requireSsl="false" />
    </federatedAuthentication>
    <applicationService>
      <claimTypeRequired>
        
        <claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" optional="true" />
        <claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" optional="true" />
      </claimTypeRequired>
    </applicationService>
    <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <trustedIssuers>
        <add thumbprint="6C6CE1DA53CE9F34F9DB4FFFAADDA8D84468C6BF" name="http://localhost:2511/MVCRP_STS/" />
      </trustedIssuers>
    </issuerNameRegistry>
</service>
</microsoft.identityModel>

Algunos de estos elementos ya los hemos comentado, aún así, para no tener que andar viajando de entrada a entrada, volveremos a destacar los más importantes:

audienceUris: Nos permite indicar la URI del cliente ( Relay Party), de forma general, el STS comprueba si el RP es válido para trabajar con el STS por medio del AudicenUri que se establece aquí.
IssuerNameRegistry: Mecanismo para comprobar que el certificado que utiliza el STS para cifrar los tokens es admisible por el RP, por defecto siempre se incluye un mecanismo que comprueba el thumbprint. El asistente, al crear un nuevo STS nos ha incluido un certificado llamado STSTestCert ( certificado autogenerado ) cuyo thumbprint es el que se ve aquí. Hablaremos más adelante sobre algún detalle de este certificado.

Otro de los detalles importantes en cuanto al cambio de la configuración de nuestro web.config, es que se han incluído dos nuevos módulos WSFAM y la SAM:

 <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true">
      <add name="WSFederationAuthenticationModule" 
           type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
           preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" 
           type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
           preCondition="managedHandler" />
    </modules>

Estos módulos se encargan realmente de todo el trabajo, de redirigir las peticiones de usuarios no autenticados al STS, de guardar el token en la sesión, de recuperar este token entre distintos Request, y alguna cosa más que por ahora no es necesario comentar. Llegados hasta aquí, parece que todo el trabajo está hecho y comentado o sea que vamos a probar nuestro ejemplo, hacemos F5 y vemos que nuestro cliente MVC ( el RP ) automáticamente hace una redirección al STS para autenticarse en esta pieza, en nuestro ejemplo la uri de redirección sería algo como la siguiente:

http://localhost:2511/MVCRP_STS/Login.aspx?ReturnUrl=%2fMVCRP_STS%2fdefault.aspx%3fwa%3dwsignin1.0%26wtrealm%3dhttp%253a%252f%252flocalhost%253a1477%252f%26wctx%3drm%253d0%2526id%253dpassive%2526ru%253d%25252f%26wct%3d2011-10-06T08%253a46%253a50Z&wa=wsignin1.0&wtrealm=http%3a%2f%2flocalhost%3a1477%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252f&wct=2011-10-06T08%3a46%3a50Z

Fíjese que en la query string hay elementos importantes como dwsignin ( nos vamos a autenticar ) wtrealm ( el audience uri) y alguno más como el contexto de la fecha etc etc… Esta redirección nos lleva hasta la página por defecto del STS, en la cual podremos incluir nuestras credenciales. Si hemos creado el STS, lógicamente tendremos que tocar esta pieza, tanto para todo lo que tenga que ver con estilo como la implementación correcta de la autenticación, selección del repositorio etc.

Bien, una vez auténticados, en el STS por defecto no es necesario poner una password podemos ver que nos encontramos con un error de lo más explícito. Concretamente el error es:

“System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (wresult="<trust:RequestSecuri...").”

Esto, es debido a que el proceso de autenticación y creación del token implica un post a nuestro RP, concretamente podeis ver este proceso dentro del Default.aspx.cs del STS

              // Process signin request.
                SignInRequestMessage requestMessage = (SignInRequestMessage)WSFederationMessage.CreateFromUri( Request.Url );
                if ( User != null && User.Identity != null && User.Identity.IsAuthenticated )
                {
                    SecurityTokenService sts = new CustomSecurityTokenService( CustomSecurityTokenServiceConfiguration.Current );
                    SignInResponseMessage responseMessage = FederatedPassiveSecurityTokenServiceOperations.ProcessSignInRequest( requestMessage, User, sts );
                    FederatedPassiveSecurityTokenServiceOperations.ProcessSignInResponse( responseMessage, Response );
                }
                else
                {
                    throw new UnauthorizedAccessException();
                }

Para arreglar este problema tenemos dos opciones, la más rápida y también la mas mala es cambiar el modo de validación de los request a 2.0 y establecer el validateRequest de la página a false. Lógicamente esto representa un compromismo de seguridad importante que no deberíamos admitir. La otra solución, es crearnos un RequestValidator personalizado. Para ello, lo único que tendremos que hacer es agregar una entrada en el system.web de nuestro config como la siguiente:

<httpRuntime requestValidationType="MVCRP.WsFederationRequestValidator" />

Dónde WsFederationRequestValidator es el siguiente validador ( básicamente comprueba que en el request hay una clave de coleccón “wa” y es una respuesta de SignIn de un STS):

    public class WsFederationRequestValidator : RequestValidator
    {
        protected override bool IsValidRequestString(HttpContext context, 
                                                    string value, 
                                                    RequestValidationSource requestValidationSource,
                                                    string collectionKey, 
                                                    out int validationFailureIndex)
        {
            validationFailureIndex = 0;
            if (requestValidationSource == RequestValidationSource.Form &&
                collectionKey.Equals(WSFederationConstants.Parameters.Result, StringComparison.Ordinal))
            {
                if (WSFederationMessage.CreateFromFormPost(context.Request) as SignInResponseMessage != null)
                {
                    return true;
                }
            }

            return base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);
        }
    }

Ahora parece que si, que ya lo tenemos todo. Volvemos a probar y efectivamente, después de la redirección y el sigin ya podemos entrar a nuestro RP MVC:

Hasta ahora hemos visto casi todo lo relacionado con nuestro RP, y como solucionar el problema de los request no válidos, sin embargo, no sabemos por ahora nada de lo que el asistente haya hecho con respecto a nuestro nuevo STS. Algunas consideraciones interesantes son las referidas al uso de los certificados y como manejar estos en producción. A continuación detalleremos esto un poco más.

Como seguramente ya sabéis el STS genera un colección de claims y las envuelve en un token de seguridad. Este token, para mantener su privacidad y que no se pueda alterar suele ( siempre ) ir firmado con un certificado digital. Por defecto, cuando creamos un STS automáticamente el asistente FedUtil nos crea e incluye en el almacén un certificado llamado STSTestCert.

Este certificado, se utiliza, como demuestran las siguientes lineas de código, dentro del Custom Security Token Service creado por el STS para encriptar los claims:

scope.EncryptingCredentials = new X509EncryptingCredentials( CertificateUtil.GetCertificate( StoreName.My, StoreLocation.LocalMachine, encryptingCertificateName ) );

Un problema habitual, es que cuando pasamos a producción y seguimos utilizando un certificado autogenerado es que la raiz de certificación no sea de confianza, por eso, si vais a hacer algun despliegue, por ejemplo en vuestro entorno de build, con un certificado de prueba tenéis que aseguraros que este certificado también se encuentre en los certificados de confianza de la máquina ( Trusted People). A mayores, si el despliguen en vuestro entorno de build lo hacéis en IIS, tenéis también que aseguraros que el usuario que corra el pool de IIS tenga permisos para acceder a la clave privada del certificado.

Ahora, que ya hemos cerrado el tema de los certificados nos quedan algunos elementos importantes que ver:

Gestión de los claims en el cliente MVC: Bien, ahora ya hemos delegado la autenticación, pero como utilizamos el token resultado para validar por ejemplo la ejecución de uná acción de un controlador o retrigir controles en las vistas?. Respuestas a esto hay muchas, en realidad tantas como variantes de implementación podamos dar, puesto que, una vez que nos hemos autenticado con nuestro STS dentro de nuestro RP HttpContext.User contendrá un elemento de tipo IClaimsPrincipal con la información de la identidad autenticada y la lista de claims de las que dispone, es decir, con toda la información que necesitemos. De forma general, el trabajo de filtrado de acciones de controladores lo podemos hacer de forma declarativa utilizando algún filtro de autorización personalizado basado en las claims del usuario autenticado..( esto lo dejo para otra ocasión ).
Elementos no autenticados en un RP: Por supuesto, no todas las secciones de una cliente necesitan estar autenticadas, sin embargo, tal y como lo hemos hecho en nuestro ejemplo si tenemos este comportamiento. Para modificarlo, y decidir que controladores necesitan autenticación podríamos realizar los siguientes pasos:

Establecer el allow users a todos en nuestro elemento authorization de configuración del RP ( <allow users="*"/>)
Crear un filtro de autenticación que obligara a los controladores (o acciones ) en los que lo situemos a realizar la autenticación con el STS, es decir, algo similar a lo siguiente:

   [AttributeUsage(AttributeTargets.Class|AttributeTargets.Method)]
    public class WIFAuthenticationFilter
        :FilterAttribute,IAuthorizationFilter
    {
        public void OnAuthorization(AuthorizationContext filterContext)
        {
            if (!filterContext.HttpContext.User.Identity.IsAuthenticated)
            {
                var fam = FederatedAuthentication.WSFederationAuthenticationModule;

                var signIn = new SignInRequestMessage(new Uri(fam.Issuer), fam.Realm)
                {
                    Context = GetReturnUrl(filterContext.RequestContext).ToString(),
                    HomeRealm = "http://localhost:3299/Home/Index"
                };
                var result = new RedirectResult(signIn.WriteQueryString());
                filterContext.Result = result;
            }
        }
        private static Uri GetReturnUrl(RequestContext context)
        {
            var request = context.HttpContext.Request;
            var reqUrl = request.Url;
            var wreply = new StringBuilder();

            wreply.Append(reqUrl.Scheme); // e.g. "http"
            wreply.Append("://");
            wreply.Append(request.Headers["Host"] ?? reqUrl.Authority);
            wreply.Append(request.RawUrl);

            if (!request.ApplicationPath.EndsWith("/", StringComparison.OrdinalIgnoreCase))
            {
                wreply.Append("/");
            }

            return new Uri(wreply.ToString());
        }
    }

SignOut: Lógicamente si nos autenticamos, también tenemos que tener un mecanismo de LogOf, para ello en WIF, podemos recurrir al WSFederationAuthenticationModule.FederatedSignOut

Os cuelgo una aplicación de ejemplo aquí.

Espero que os resulte de interés

Unai

EF vNext- Migrations 0.7.0.0

Unai — Thu, 22 Sep 2011 11:57:45 GMT

Las dos últimas entradas de este blog trataban sobre una de las novedades ( una de las importantes ) que traerá la próxima version de EF llamada Migrations. Ayer mismo, sacaron de forma publica una nueva revisión ( aún en version alfa, 0.7.0.0) que presenta algunas novedades interesantes que me gustaría comentar aquí. Lógicmente no volveremos a hacer los walkthrough de los post anteriores ( por supuesto puede también revisar el blog del grupo de ADO.NET con sus propias guias), sino que solamente vermos algunas de las novedades introducidas.

Puerta de entrada para introducir datos con la migración

Lo primero que llama la atención con esta nueva versión es que la clase Settings, creada automáticamente cuando se agrega el paquete de migraciones, además de las opciones anteriores para establecer los generadores a utilizar nos proporciona un método para realizar un Seed de los datos.

    public class Settings : DbMigrationContext<CRMUnitOfWork>
    {
        public Settings()
        {
            AutomaticMigrationsEnabled = false;
            SetCodeGenerator<CSharpMigrationCodeGenerator>();
            AddSqlGenerator<SqlConnection, SqlServerMigrationSqlGenerator>();
        }
        protected override void Seed(CRMUnitOfWork context)
        {
            if (!context.Customers.Any())
            {
                context.Customers.Add(new Customer() { FirstName = "Unai" });
            }
            base.Seed(context);
        }   
    }

Este método Seed se ejecuta automáticamente cada vez que se hace una migración a la ultima versión. Bueno, aunque esto, aún parece que esta pillado con pinzas, sobre todo porque habría que discutir como afectan las migraciones hacia atrás con respecto a los datos etc… Es decir, parece que con todo lo que tenga que ver con Data Motion aún hay mucho por jugar. Veremos en las siguientes versiones que cariz toma esto.

Update-Database –Verbose

El nuevo flag –Verbose nos permite ver en nuestro Package Manager la información del SQL a generar para realizar la actualización de la base de datos después de una migración. Así por ejemplo si ejecutamos este comando podríamos ver cosas como las que podemos observar en la figura de la derecha.

Downgrades

En esta versión ya empezamos a tener la posibilidad de deshacer migraciones o situarnos en alguna migración en concreto, algo que ellos llaman downgrades. Supongamos que estamos trabajando con este paquete y realizamos por ejemplo dos migraciones. La inicial de nuestro proyecto, First, y después una llamada AddNotesProperty. Pues bien, esta segunda migración nos generaría un código como podría ser el siguiente:

    public partial class AddNotesProperty : DbMigration
    {
        public override void Up()
        {
            AddColumn("Customers", "Notes", c => c.String());
        }
        
        public override void Down()
        {
            DropColumn("Customers", "Notes");
        }
    }

En este pequeño fragmento podemos ver como tenemos un método para “deshacer” la migración, en nuestro casi algo tan simple como eliminar la columna previamente creada en la tabla Customers. Ahora,

si quisiéramos movernos por ejemplo a la versión inicial de la base de datos podríamos ejecutar el siguiente comando: Update-Database –TargetMigration:First. Esto es realmente importante si por ejemplo nos queremos mover a una versión de código determinada y tenemos una base de datos por ejemplo posterior. Gracias a que todas las migraciones las tenemos disponibles como código dentro de la carpeta Migrations podemos realizar esta tarea sin dificultad ninguna.El flag –TargetMigration tiene un argumento especial que es 0 y nos permite movernos directamente a la primera migración.

Notas:

Aunque en esta versión han arreglado la dependencia con SqlExpress, no se podía utilizar el paquete de migraciones sino se disponia de una instancia con nombre .\SQLEXPRESS ( o en su defecto un alias) aún hay cosas que serían deseables y que no están. Como por ejemplo la posibilidad de usar toda la artillería de migraciones fuera de Visual Studio o el uso de Data Motion.

Saludos

Unai

EF vNext-Migrations II

Unai — Thu, 15 Sep 2011 21:20:41 GMT

En la anterior entrega hemos visto como usar el nuevo paquete que a salido del equipo de Data Development en Redmon. En esta nueva entrada, intentaremos continuar con algunos detalles importantes que nos permitan comprender mejor con que estamos tratando.

Migraciones automáticas

Si recuerda, cada vez que ejecutamos una migración por medio del comando Add-Command se incorpora a nuestro proyecto el sacaffolding de la migración por medio de una clase de tipo DbMigration. En alguna ocasión, puede que no nos interese tener estos ficheros de scaffolding y simplemente ejecutar la migración. A este proceso, se le conoce como migración automática. Para mostrar esto partiremos del código de la anterior entrada y modificaremos nuestra clase Customer agregandole una nueva propiedad.

    public class Customer
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public int Age { get; set; }
    }

Bien, ahora para actualizar nuestro esquema, solamente tenemos que ejecutar el comando Update-Database, sin necesidad de crear la migración. Para que esto funcione necesitamos establecer en la configuración de las migraciones, nuestra clase Settings, que habilite las migraciones automáticas, tal y como podemos ver en el siguiente fragmento.

    public class Settings : DbMigrationContext<CRMUnitOfWork>
    {
        public Settings()
        {
            AutomaticMigrationsEnabled = true;
            SetCodeGenerator<CSharpMigrationCodeGenerator>();
            AddSqlGenerator<SqlConnection, SqlServerMigrationSqlGenerator>();

            // Uncomment the following line if you are using SQL Server Compact 
            // SQL Server Compact is available as the SqlServerCompact NuGet package
            // AddSqlGenerator<System.Data.SqlServerCe.SqlCeConnection, SqlCeMigrationSqlGenerator>();
        }
    }

Si bien la actualización automática del esquema es util, puede llegar a ser necesario disponer del script de actualización en vez de la ejecución de la migración directamente. Para disponer de este script, solamente tenemos que agregar el flag Script al comando anterior. La siguientes lines T-SQL se corresponden a una nueva migración en la que se ha incluido una propiedad Address.

BEGIN TRANSACTION;
SET XACT_ABORT ON;
ALTER TABLE [Customers] ADD [Address] [nvarchar](max);
INSERT INTO [__MigrationHistory] (Migration, CreatedOn, Hash, Model) VALUES ('Automatic Migration', getdate(), 0x4EE620C904605E84D8F981B7A5B861D15FFB6BC5DB8F9B9945E924EB798B72A4, 0x1F8B0800000000000400ECBD07601C499625262F6DCA7B7F4AF54AD7E074A10880601324D8904010ECC188CDE692EC1D69472329AB2A81CA6556655D661640CCED9DBCF7DE7BEFBDF7DE7BEFBDF7BA3B9D4E27F7DFFF3F5C6664016CF6CE4ADAC99E2180AAC81F3F7E7C1F3F22FEC7BFF71F7CFC7BBC5B94E9655E3745B5FCECA3DDF1CE4769BE9C56B36279F1D947EBF67CFBE0A3DFE3E8374E1E9FCE16EFD29F34EDF6D08EDE5C369F7D346FDBD5A3BB779BE93C5F64CD78514CEBAAA9CEDBF1B45ADCCD66D5DDBD9D9D83BBBB3B777302F111C14AD3C7AFD6CBB658E4FC07FD79522DA7F9AA5D67E517D52C2F1BFD9CBE79CD50D317D9226F56D934FFECA3A74FBE282EEAAC253C9A8FD2E3B2C80887D77979FE9E08ED3C04421FD9AEA8B35342AABD7E73BDCAB9C3CF3E3A59376DB5C86BBF15B5FBBDF2EBE003FAE8655DADF2BABD7E959FEBBB67B38FD2BBE17B77BB2FDAD7BC77D03DFDB66CEFED7D94BE5897653629E983F3AC6CF28FD2D5A78F5EB7559D7F9E2F7322423E7B99B56D5E2FF16ECEE82B191EAD3EBD1D251EDEDDD90325EE66CB65D5325D7B8877D07C56D44D8B5F0DB6AFDB9AF8E5A3F459F12E9F3DCF9717EDDC62FC45F6CE7C42BF7E947EB52C88BDE8A5B65EE7FE08E5EFCD3D3FCF7E8E3A3E5D6445F943EFF5F8C28E7488216E00309BD579D3FC2C23FEF8AE939C8DF2444AE48BBCCD66599BFD48A4023459EF7D3B6BE63FA753457AB8CD0A2283D17FAFBE20D8ED97E7DFADEAB79D1993375EE76D475712B3B92E44338FAD1EED52A10BC46390181C9F7FA2C3B2037016E4AE9810636AEE0ED89AC75F64AB1551DCB33DFA49FA5A0CCFC9F6EBF737310B817177DA442C8DC5D6F6447C985DE49D6FA96BC29495EE531AF924030F9CCC16FD66B7992ED35777D6BAE2E7886FDEC0EFF2966F83DDE47620380A3EA3412D4894787C3A3AC264C8BEEACBAFA75999D511713EA9CAF56239A41236BDED192E1F88F7F1ED613953E483729FDE1E92DA161F8C7E747B186C297C08FCC17BBC6F0C4500C37CD887F3F86E676EBBECE3E9196DD951DC5D86BC15BB06FAE16B73ECA01962303731EDC6B77F76F8D6B30E3E10EFE31FF20CF5F46DB789EDDDEADD8E7E7DACBA2E50C23CFEAEC3DF537ED2E4A394887459CCA0F85E5F376DBE18A3C1F8F52F2A4FCA82C6EB1A7C912D8BF3BC69DF546F73042FA49BBF7EE4608D7BD3CCCAFFB7860F05867FA357F39ECE64CFED5F5E66F5749ED55B8BECDD9DF7F56DBBAEFC07010BDCF30F82E4B9DC4CC4F7A451C7E17E0F54FEBFE144FFAC3096A7C7BE61B2F51CDA9E23356076BA12BCC9A7157DF4D947B349450310443D6FF8F62EEF4D1E6FACA36FC225EEABE2C777FD0CCDE3A779535C3810C8D72CF3298CA9036ADA9C2DCF2B33BF344A1F23D3A43BFD8AFF71DD16E7D9B4A5AFA724431CFEFC6456AE59BE27F9EC6CF9E5BA5DADDBE3A6C91793F2DA1FEFE3BB9BFB67BF3FC4F9F1972B7607BE8921109A050D21FF72F9645D94338BF7B33EFB0F81006BAA4C115614FE11B88B6B0BE945B5BC252025DFD37C952F21916FF2C5AA2460CD97CBD7D9653E8CDBCD340C29F6F86991914FB5F029289F2826AF33EAD9EB823AF0DF70FDD19FC4AE941E3CFA7F020000FFFFDE9A70EE93140000);
DELETE FROM [EdmMetadata];
INSERT INTO [EdmMetadata] ([ModelHash]) VALUES ('7A1D3FB94B39A8198EF177EDE6FF734EE97083E664B613C98EA9F74BA468B42F');
COMMIT TRANSACTION;

Con esto hemos acabado esta primera mini-serie sobre las migraciones. Esperemos que se siga trabajando en completar nuevas features y seguir escuchando todo el feedback que la comunidad está aportando.

Saludos

Unai