O bruxo mobile

NoSQL para programadores .NET

2012-05-03T08:10:13Z

El 29 de Mayo tendré el placer de impartir un curso presencial sobre NoSQL en Madrid, con un especial interés en dos productos muy conocidos como son MongoDB y RavenDB. La agenda y los detalles de horarios y localización los puedes ver aquí.

Si trabajas en .NET y quieres saber más sobre las bases de datos documentales y en concreto sobre los productos anteriormente mencionados no te lo pienses y apúntate, no te arrepentirás.

Saludos

Unai

Cuidado con EF 4.3.X si vienes desde 4.2 o anteriores…

2012-04-06T11:13:00Z

Bueno, el título es bástante explicativo verdad, para todos aquellos que tengais un proyecto en 4.1 o 4.2 y estéis pensando en migrar a la ultima versión del paquete de NuGet tener en cuenta que hay algunas características de los mapeos rotas y por lo tanto el proceso de cambio os puede dar algún que otro quebradero de cabeza. El porque de estas regresiones se debe a la introducción de Migraciones en la version 3 y a la inclusión de este API en el pipeline del proceso de creación del modelo y base de datos.

A continuación me gustaría exponeros algun ejemplo de elemento rotos entre 4.2 y las versiones superiores, con Migrations.Si quiere comprobarlo usted mismo puede probar los ejemplos con 4.2 utilizando el siguiente comando de NuGet, Install-Package EntityFramework –Version 4.2

TPH - Partiendo del siguiente modelo simple:

public class Product

    public int Id { get; set; }

public class Software : Product { }

public class Book : Product { }

En EF 4.2 podíamos hacer:

protected override void OnModelCreating(DbModelBuilder modelBuilder)

    modelBuilder.Entity<Product>()

                .Map<Software>(emc =>

                    emc.Requires("discriminator").HasValue("software");

})

                .Map<Book>(emc =>

                    emc.Requires("discriminator").HasValue("book");

});

Ahora, en EF 4.3.1 si lo intentamos tendremos el siguiente mensaje de excepción:

“Map was called more than once for type 'Software' and at least one of the calls didn't specify the target table name.”

Por supuesto, como en casi todos los casos podemos tener un workaround (algo que por supuesto no tendríamos porqué hacer), que sería mapear esto como sigue:

modelBuilder.Entity<Software>()

            .Map(emc =>

                emc.Requires("discriminator").HasValue("software");

});

modelBuilder.Entity<Book>()

            .Map(emc =>

                emc.Requires("discriminator").HasValue("book");

});

Relaciones consigo mismo ( hay otros casos.. )

Imaginemos que tenemos la típica tabla de relación consigo mismo, padres e hijos, como por ejemplo la representada por la siguiente entiedad:

public class ProcessedTransaction

    public int  Id { get; set; }

    private HashSet<ProcessedTransaction> childTransactions;

    public int? ParentTransactionId { get; set; }

    public virtual ProcessedTransaction ParentTransaction { get; private set; }

    public virtual ICollection<ProcessedTransaction> ChildTransactions

get

            if (this.childTransactions == null)

                this.childTransactions = new HashSet<ProcessedTransaction>();

            return this.childTransactions;

set

            this.childTransactions = new HashSet<ProcessedTransaction>(value);

Este escenario, lo podríamos mapear como sigue:

this.HasKey(t => t.Id);

this.Property(t => t.Id)

    .HasColumnName("ProcessedTransactionId")

    .HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity)

    .IsRequired();

this.HasMany(t => t.ChildTransactions)

    .WithRequired()

    .HasForeignKey(ct => ct.ParentTransactionId)

    .WillCascadeOnDelete(false);

Sin embargo, si intentamos hacer esto mismo en EF 4.3 tendrímos la siguiente excepción de duplicación de índice ( si, ahora EF hace también el trabajo de creción de índices en la base de datos)

“The operation failed because an index or statistics with name 'IX_ParentTransactionId' already exists on table 'ProcessedTransactions'.”

Bueno, es cierto que esto es un bug que se debe a que puede que el mapeo no sea “correcto del todo” (puesto que estariamos creando 2 asociaciones en vez de 1) pero no es menos cierto que si en 4.2 funcionaba en 4.3 también debería, y, sino es así, DEBERIAN NOTIFICAR QUE CAMBIOS ROMPEN CON LA VERSIÓN ANTERIOR.

Conclusiones

Lo que acabamos de poner aquí son solamente algunos de los ejemplos de cosas que pueden levantarnos algún que otro dolor de cabeza si migramos nuestras soluciones a versiones > 4.3. Por eso, como reza el titulo del post, ojo si vais a migrar vuestras aplicaciones porque el camino no es como debería, exento de trabajo…

Saludos

Unai

EF DateTime2 y el índice perdido

2012-03-27T16:52:34Z

the bug hunting!

Hoy me han remitido un caso muy curioso de EF y el tratamiento de los campos DateTime. Básicamente, lo que me comentaban era que EF generaba una consulta incorrecta incluyendo un CAST a DateTime2, con lo cual hacía imposible la utilización del índice que la base de datos tenía sobre esta columna. Para seros sinceros, me sonó raro, puesto que es habitual ver el profiling de las consultas y me hubiera cantado a la primera, por lo que me puse a investigar el tema. Como siempre, lo primero es una aplicación de mínimos y por ello, nada más tonto que lo siguiente:

public class UnitOfWork

   :DbContext

   public IDbSet<Sample> Samples { get; set; }

ublic class Sample

   public int Id { get; set; }

   public DateTime Fecha { get; set; }

Ahora, solamente nos queda tirar una consulta y ver que se está ejecutando:

static void QueryWithoutCastToDateTime2()

    using (UnitOfWork uow = new UnitOfWork())

        DateTime fechaInit = DateTime.Now.AddDays(-2);

        DateTime fechaFin = DateTime.Now;

        var result = uow.Samples.Where(d => fechaInit < d.Fecha && d.Fecha < fechaFin).ToList();

exec sp_executesql N'SELECT

[Extent1].[Id] AS [Id],

[Extent1].[Fecha] AS [Fecha]

FROM [dbo].[Samples] AS [Extent1]

WHERE (@p__linq__0 < [Extent1].[Fecha]) AND ([Extent1].[Fecha] < @p__linq__1)',N'@p__linq__0 datetime2(7),@p__linq__1 datetime2(7)',@p__linq__0='2012-03-25 18:16:30.5246971',
@p__linq__1='2012-03-27 18:16:30.5251972'

Bien, perfecto.. No veo el problema que se comenta!!!!!!!!! Revisando el código en el que aparecía este problema, buscando cualquier nota diferente como que estuviera forzando el tipo a DateTime2 etc.. nos dimos cuenta que la única diferencia era que en su ejemplo los campos eran Nullables. Por lo tanto, probamos a cambiar el ejemplo tonto anterior haciendo uso de DateTime?.

static void QueryWithCastToDateTime2()

    using (UnitOfWork uow = new UnitOfWork())

        DateTime? fechaInit = DateTime.Now.AddDays(-2);

        DateTime? fechaFin = DateTime.Now;

        var result = uow.Samples.Where(d => fechaInit < d.Fecha && d.Fecha < fechaFin).ToList();

Revisando la consulta con el profiler nos dimos cuenta de que efectivamente, si hacemos uso de DateTime? las consultas generan un CAST incorrecto que tira por tierra nuestros índices…

exec sp_executesql N'SELECT

[Extent1].[Id] AS [Id],

[Extent1].[Fecha] AS [Fecha]

FROM [dbo].[Samples] AS [Extent1]

WHERE

(@p__linq__0 <  CAST( [Extent1].[Fecha] AS datetime2))

AND

( CAST( [Extent1].[Fecha] AS datetime2) < @p__linq__1)'

,N'@p__linq__0 datetime2(7),@p__linq__1 datetime2(7)',

@p__linq__0='2012-03-25 18:17:38.1257814',

@p__linq__1='2012-03-27 18:17:38.1262814'

Por supuesto esto es un bug, un bug que esperemos que arreglen en la siguiente versión, mientras tanto, ya sabéis, cuidado con los DateTime?.

P.d: Vizoso, gracias por reportar el bug!!

Saludos

Unai

EF, inicializadores, migraciones y datos de referencia

2012-03-21T18:12:28Z

Hace unos pocos dias, revisando una base de código me encontré con un uso “diferente” de los inicializadores a como yo los había usado anteriormente. Concretamente, la linea(s) de código que me llamaron la atención fueron las siguientes:

Database.SetInitializer(new OrmViewRepositoryInitializer(new OrmRepositoryInitializer(new DropCreateDatabaseIfModelChanges<OrmRepository>())));

Un inicializador, que está decorado con otro inicializador??? Que raro, parece una complicación excesiva ¿no?. El caso es que, revisando su uso, se puso encima de la mesa que este decorador estaba creado para poder mantener un inicializador compartido, datos referenciales entre los juegos de pruebas y el producto. En definitiva, básicamente, el objetivo de esto es no tener que escribir dos seed de datos diferentes para los inicializadores de pruebas asumiendo que, generalmente, en tests se tiene un DropCreateDatabaseAlways y en producto un DropCreateDatabaseIfModelChange. Ummm, puedo llegar a entenderlo, sin embargo, se me plantean una seria de dudas con respecto a esto. ¿De verdad es necesario compartir datos referenciales entre el juego de tests y la base de datos de producción? ¿Si tengo un seed compartido, es esta la forma más simple de hacerla?

¿De verdad es necesario compartir datos referenciales entre el juego de tests y la base de datos de producción?

Para ser sinceros yo creo que no, por lo menos en lo que yo entiendo que son datos referenciales. ¿De verdad necesito tener toda la coleccion de paises, provincias, clientes por defecto etc etc etc.. para mis juegos de prueba? La experiencia me dice que no, de hecho, la experiencia me dice que generalmente los datos referenciales no dan una cobertura muy buena a los casos que se te suelen presentar, por ello, para las pruebas, utilizas datos mucho más límites, por ejemplo pensamos en juegos de caracteres diferentes, expresiones regulares más complejas etc etc que no solemos tener en datos maestros que suelen representar en lineas generales la misma prueba y no ofrecen mucha cobertura.

Otra de las razones por la cual tener todos los datos referenciales en la base de datos de prueba no tiene porque ser buena idea tiene que ver con el coste. Generalmente, cuando testeamos elementos de EF sin utilizar un “In Memory ObjectSet” recurrimos a la utilización de un AssemblyInitialize, o su correspondiente sino usas MSTests, en nuestras pruebas, algo, similar a lo siguiente:

[AssemblyInitialize()]

public static void Initialize(TestContext testContext)

   Database.SetInitializer(new DropCreateDatabaseAlways<OrderingUnitOfWork>());

Con esto, básicamente, lo que estamos haciendo es configurar un inicializador para EF antes de que se ejecute cualquier prueba dentro del ensamblado de tests. Concrétamente, estamos haciendo que se borre y se recree la base de datos de forma automática. Cuando, en nuestras pruebas queremos tener un conjunto dado de datos entonces hacemos una pequeña variante, creándonos un inicializador como podría ser el siguiente:

public class TestsInitializer

    :DropCreateDatabaseAlways<OrderingUnitOfWork>

    protected override void Seed(OrderingUnitOfWork context)

        //TODO add test data

NOTA: Tal y como se enseño aquí, una de las novedades que se introdujo en EF 4.3.x fué la aparición de una nueva sección de configuración donde podemos especificar nuestros inicializadores, con lo cual, el trabajo de utilizar un AssemblyInitialize podría ser sustituído por una entrada en el archivo de configuración. Puede obtener más información sobre esto aquí.

El problema de incluir todos los datos referenciales en nuestro TestsInitializer se presenta en forma de coste, si cada vez que ejecutamos la primera de las pruebas se borrará, creará y poblará la base de datos no queremos que esto consuma un excesivo tiempo, puesto que, como todos ya sabemos, si las pruebas son viscosas o tardan mucho en ejecutarse acaban por desesperar y no se ejecutan con la frecuencia que deberían ejecutarse.. Por lo tanto, parece buena idea el restrigir el seed de los datos a aquellos que sean de valor para las pruebas únicamente, realmente, no necesitamos datos superficiales.

Curiosamente, en la revisión de esa linea de código, en el inicializador base me encontré algo de código como el siguiente:

this.innerInitializer.InitializeDatabase(context);

if (!context.Database.SqlQuery<int>("SELECT object_id FROM sys.views WHERE object_id = OBJECT_ID(N'[dbo].[OrdersView]')").Any())

    context.Database.ExecuteSqlCommand(@"CREATE VIEw

[dbo].[OrdersView]

AS

SELECT

rs.Id AS OrderId,

rs.State as StateValue

ers");

…

Si nos fijamos, parece que al tener un inicializador base, fué dificil quitarse la tentación de escribir algo más que inicialización ¿verdad?. La creación de estas vistas no es data-motion sino que pertenece al esquema y como tal debería de ser tratado. Para ello, en EF tenemos ( incluida directamente en el paquete) desde la version 4.3, actualmente 4.3.1, la posibilidad de utilizar migraciones, elementos sobre los que ya he hablado aquí y aquí en este mismo blog. Como todos sabemos, las aplicaciones cambian, los esquemas cambian y por lo tanto las vistas también, incluir esto junto a nuestras migraciones nos hará todo un poco más sencillo, puesto que aquí se aplican los mismos argumentos que con el resto de elementos de nuestra base de datos. Por lo tanto, en nuestros métodos Up o Down podríamos hacer de una forma sencilla el trabajo de crear/eliminar/modificar una vista por medio del método Sql de nuestras clases DbMigration.

Sql("CREATE VIEW...

¿Si tengo un seed compartido, es esta la forma más simple de hacerla?

Bien, supongamos que por lo que sea decidimos que los argumentos anteriores no son válidos y necesitamos/queremos tener un seed compartido. Podemos hacer esto y mantener separados data-motion de la creación / manipulación de nuestros elementos de esquema? Bueno, vamos a intentarlo, si nos fijamos en nuestros elementos de trabajo IDatabaseInitializer<TContext> y DbMigrationsConfiguration<TContext> ámbos tienen en común la misma firma para el método de seed de datos.

protected virtual void Seed(TContext context);

Por lo tanto, en ámbos casos disponemos de una unidad de trabajo sobre la cual podremos interactuar, por lo tanto podríamos hacer algo como lo siguiente, aunque sea muy simple:

public static class DataMotion

    public static void Publish(OrderingUnitOfWork unitOfWork)

        unitOfWork.Orders.AddOrUpdate<Order>(new Order[]{

                new Order(){OrderDate = DateTime.Now.AddDays(-1),Total =100M},

                new Order(){OrderDate = DateTime.Now.AddDays(-2),Total =300M},

                new Order(){OrderDate = DateTime.Now.AddDays(-3),Total =0M},

});

y utilizarlo tanto en nuestra configuración de migraciones como en nuestros inicializadores..

internal sealed class Configuration : DbMigrationsConfiguration<OrderingUnitOfWork>

    public Configuration()

        AutomaticMigrationsEnabled = false;

    protected override void Seed(OrderingUnitOfWork context)

        DataMotion.Publish(context);

public class TestsInitializer

    :DropCreateDatabaseAlways<OrderingUnitOfWork>

    protected override void Seed(OrderingUnitOfWork context)

        DataMotion.Publish(context);

        //Add more data for specific tests

Conclusiones

Tal y como he comentado anteriormente, en mi opinión, los juegos de datos para testing son diferentes de los datos que solemos publicar junto con nuestro esquema, por ello,es conveniente separar entre inicializadores y migraciones los datos que se publicarán, de hecho, generalmente las bases de datos son diferentes ( en nombre y/o instancia ). Con la llegada de Migrations, ahora, en EF tenemos una forma simple de gestionar el ciclo de vida de nuestros esquemas, cambios, bajadas de versiones y también Data Motion.

Saludos

Unai

Implementando CORS en ASP.NET Web API

2012-03-05T21:12:00Z

Seguramente, los que leeis geeks ya estaréis al tanto de la salida de ASP.NET WebAPI para la siguiente versión de ASP.NET MVC, de hecho, en esta misma comunidad, gente como Jose Maria Aguilar y Eduard Tomás ya han hecho unos cuentos posts interesantísimos sobre el tema, no dejéis pasar la oportunidad de leerlos y aprender de ellos, os lo recomiendo encarecidamente, si me lo permitís. A mi en este post, me gustaría tratar un tema importante cuando nos enfrentamos a hacer un API REST que pueda ser utilizado por otros sitios sin tener que recurrir a JSON padding, por comodidad y por la limitación del verbo a utilizar. Cross-Origin Resource Sharing, usualmente conocido como CORS, es una especificación que permite habilitar de forma confiable el acceso across-domain-boundaries de forma que no tengamos que utilizar jsonp y soportando cualquier tipo de verbo para la operación.

Antes de intentar explicar detenidamente como funciona y como implementar CORS haremos un pequeño ejemplo con Web API que trataremos de consumir desde otro sitio y veremos como este no puede ser consumido directamente, para, posteriormente ir implementando CORS directamente. La idea del ejemplo es extremadamente simple, un método GET y un POST para un supuesto producto.

public class ProductController

    :ApiController

    public IEnumerable<Product> GetProducts()

        var products = new List<Product>()

            new Product(){Id  =1, Name ="Windows Power Shell in Action",Description ="Second Edition. Bruce Payette"},

            new Product(){Id  =1, Name ="Git in Action",Description =""}

};

        return products;

    public HttpResponseMessage<Product> PostProduct(Product product)

return new HttpResponseMessage<Product>(product, HttpStatusCode.OK);

Una vez hecho esto, y el consiguiente mapeo de la ruta, podríamos desde nuestro sitio web utilizar este API, por ejemplo, el código de la siguiente vista nos mostraría como recuperar y mostrar la lista de productos de este API.

<div id="products">

Products...

</div>

<script type="text/javascript">

    $.ajax({

        url: "http://localhost:1042/api/product/",

        type: "GET",

        success: function (data) {

            $.each(data, function (index, item) {

                $("#products").after("<p>" + item.Name + "</p>");

});

},

        error: function (jqXHR, settings, exception) {

            $("#products").html("error loading products...");

});

</script>

Sin embargo, como muchos ya sabéis, si intentamos hacer esto mismo desde otro sitio no tendremos el resultado esperado, puesto que esa llamada está fuera del dominio del cliente y los navegadores actuales restringen esta funcionalidad. Tal y como comentamos anteriormente, podríamos utilizar JSONP para solventar este problema, sin embargo, aunque es una medida que funcionan tiene varios inconvenientes. En primer lugar implica un trabajo de cliente adicional y en segundo lugar solamente estaría soportado el verbo GET. Para solventar este problema, veremos como funciona CORS y posteriormente como implementarlo en ASP.NET Web API

Como funciona CORS?

CORS se basa en dos peticiones fundamentales, un cross-orgin-request y un preflight-request, los cuales expondremos de una forma sencilla a continuación.

cross-origin-request consiste básicamente en el envío por parte de quien solicita un recurso compartido de una cabecer Origin, con el valor del cliente que desea consumir ese recurso. Por parte del servidor, se hace la lectura de esa cabecera y se comprueba que puede utilizar un determinado recurso. Una vez comprobado, el servidor en la respuesta, envía una cabecera Access-Control-Allow-Origin con el valor del cliente admitido, valor no case sensitive que tienen que coincidir con el emisor. En realidad, este proceso se podría complicar un poco más incluyendo credenciales, no obstante, nosotros no lo utilizaremos, si alguien quiere ampliar la información puede hacerlo aquí.
preflight-request es un request utilizado para, a mayores de garantizar el origen , ver que métodos pueden utilizarse.

Implementando CORS en Web API

Todos los que habéis leido a Eduard y José Maria sabréis que entre las bondades de ASP.NET Web API está la extensibilidad, pués bien, una de las características de esta extensibilidad es la de los MessageHandler. Estos elementos, expuestos en WebAPI generalmente por medio de DelegatingHandler nos permiten introducirnos en el pipeline del proceso de una petición HTTP de una forma muy sencilla.

En nuestro caso, empezaremos por crearnos nuestro handler tal y como vemos.

public class CORSMessageHandler

    :DelegatingHandler

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

        return base.SendAsync(request, cancellationToken);

Si registramos este handler, tal y como vemos a continuación en nuestro Application_Start, y ponemos un punto de ruptura en el método SendAsync veremos como ya tenemos una manera de “enchufarnos” al procesamiento de una petición a nuestro servicio de Web API.

GlobalConfiguration.Configuration.MessageHandlers.Add(new CORSMessageHandler());

Para empezar intentaremos resolver el cross-origin-request, si ha leído la especificación, básicamente lo que haría el navegador es incluir en nuestra petición una cabecera Origin, cabecera con el valor del dominio que intenta llamar al API. Para otorgar al dominio como dominio válido, la petición, además de la respuesta debería incluir una cabecera llamada Access-Control-Allow-Origin con el valor de ese dominio válido. Modificando nuestro handler anterior como sigue, ya tenemos, sin ninguna tarea adicional en el cliente este trabajo resuelto, simple y sencillo. Haga la prueba y fíjese como, automáticamente se hace la inclusión de esta cabecera

public class CORSMessageHandler

   :DelegatingHandler

   protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

       var corsEnabled = request.Headers

                                .Where(h => h.Key == "Origin")

                                .Any();

       if (corsEnabled)

           return base.SendAsync(request, cancellationToken)

                       .ContinueWith<HttpResponseMessage>(t =>

                           var response = t.Result;

                           response.Headers.Add("Access-Control-Allow-Origin", request.Headers.GetValues("Origin"));

                           return response;

});

       else

           return base.SendAsync(request, cancellationToken);

El segundo de los request especiales de CORS es el preflight, request que en nuestro caso no se produce puesto que no tenemos ninguna operación que no sea GET. Si hubiéramos implementado una operación con un verbo distinto, por ejemplo el POST de nuestra API Rest la primera petición que llegaría al servidor se corresponde con el request de preflight, que si ha visto la especificación se corresponde con un request con el verbo OPTIONS. La respuesta a esta petición debería incluir un pare de cabeceras como especifica la documentación con los métodos y valores especiales de headers aceptados. Una vez hecho el preflight, la llamada se realizará de forma normal. Pues bien, una vez terminada, más o menos, la explicación, la implementación ( un poco ASM ) sería la siguiente:

public class CORSMessageHandler

    :DelegatingHandler

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

        var corsEnabled = request.Headers

                                 .Where(h => h.Key == "Origin")

                                 .Any();

        bool preflight = request.Method == HttpMethod.Options;

        if (corsEnabled)

            if (preflight)

                return Task.Factory.StartNew<HttpResponseMessage>(() =>

                    var response = new HttpResponseMessage(System.Net.HttpStatusCode.OK);

                    response.Headers.Add("Access-Control-Allow-Origin", request.Headers.GetValues("Origin"));

                    response.Headers.Add("Access-Control-Allow-Headers", request.Headers.GetValues("Access-Control-Request-Headers"));

                    response.Headers.Add("Access-Control-Allow-Methods", "POST");

                    return response;

});

            else

                return base.SendAsync(request, cancellationToken)

                            .ContinueWith<HttpResponseMessage>(t =>

                                var response = t.Result;

                                response.Headers.Add("Access-Control-Allow-Origin", request.Headers.GetValues("Origin"));

                                return response;

});

        else

            return base.SendAsync(request, cancellationToken);

NOTA: El código anterior es una implementación muy simple y sin refactoring alguno, no debería utilizarse sin trabajarla un poco. Fíjese en el hardcoded de los métodos soportados etc etc…

Bueno, esto parece que ha sido todo, espero que os haya gustado…

Saludos

Unai

EF 4.3.1, EF 5 …y el camino

2012-02-29T20:07:22Z

Bueno, seguro que a estas alturas todos estareis instalando las versiones preliminares de VS 2011 y probando muchas de las nuevas características.. y también seguro que los que estéis interesados en EF habréis leido algunas de las novedades de EF 5 mediante el post del grupo de producto. Pues bien, a mayores de EF 5 y el paquete de nuget para el también se ha actualizado el paquete de EF 4.3 pasando a EF 4.3.1. Aunque el post anterior del grupo de producto explica los fix que se han hecho me gustaría hablar aquí sobre un par de elementos de interes de este nuevo paquete.

LocalDB

Muchos de vosotros ya conoceréis que en VS 2011 tendremos algo llamado LocalDB, que vendrá a ayudar a aquellos que no tengan una instancia de SQLEXPRESS o SQL. Pues bien, en el nuevo paquete, así como en 5.0, cuando hacemos un install-package el proceso de instalación del paquete revisa si tenemos instalada un SQLEXPRESS, en caso contrario, setea como provider factory por defecto el uso de localdb. De hecho, se incluye en la configuración de Entity Framework este valor.

<entityFramework>

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

      <parameters>

        <parameter value="Data Source=(localdb)\v11.0; Integrated Security=True; MultipleActiveResultSets=True" />

      </parameters>

    </defaultConnectionFactory>

  </entityFramework>

Para aquellos, que como yo, tenemos un alias para SQLEXPRESS tenemos que acordarnos de modifcar esta sección de configuración o bien utilizar Database.DefaultConnectionFactory para sobreescribir este valor.

Migraciones desde una base de datos existente

Hasta ahora, con EF 4.3, las migraciones de una base de datos existente eran un poco coñazo, puesto que en la primera migración teníamos que revisar que elementos forman parte de la base de datos actual y borrarlos de nuestra clase DBMigration. Pues bien, ahora, con EF 4.3.1 nuestro comando Add-Migration tiene un nuevo flag, llamado –IgnoreChanges que nos permite indicar al proceso de creación de la migración que no incluya aquella información que está ya presente en la base de datos, puesto que estamos ignorando los primeros cambios que hacermos..

Bueno, aquí se acaba este pequeño posts escrito con premura desde Seattle..

Saludos

Unai

MAD.NUG–NoSQL y RavenDB

2012-02-12T10:56:17Z

El próximo Jueves, 16 de Febrero a las 19:00 tendré el placer de estar con mis amigos de MAD.NUG para dar una introducción a RavenDB. A lo largo del evento trataremos de ver desde elementos introducctorios acerca del mundo NoSQL y las bases de datos documentales hasta aspectos muy particulares del funcionamiento de RavenDB

Puedes registrarte aquí si te interesa el evento.

Saludos

Unai

DDD, agregados y NoSQL

2012-01-30T19:35:35Z

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…

2012-01-12T23:20:00Z

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

2012-01-12T22:57:08Z

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

2012-01-12T17:53:30Z

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..

2011-12-20T18:26:00Z

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…

2011-12-19T18:12:00Z

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

2011-12-15T20:05:16Z

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

2011-12-12T11:09:00Z

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

2011-12-09T09:35:18Z

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

2011-12-09T09:06:00Z

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

2011-12-05T10:25:40Z

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….

2011-12-01T00:10:00Z

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

2011-11-30T17:50:00Z

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