Guisa Meeting 1…

Finally it’s here: http://guisa1.eventbrite.com/, the first live GUISA event has been organized.

A new format

we want to introduce a new format, we are typically used to two main formats:

• Speaker driven events, talks, where the speaker drives the knowledge one way from himself to the audience;
• Whiteboard events where the audience discuss something and in some case there is just a moderator to keep persons on focus;

We would like the have the best of both:

• Sessions will last 90 minutes:
• The first 60 minutes are speaker driven;
• The last 30 minutes are for the discussion;
• Session must be about real world projects: the session host will introduce in the first 60 minutes the requirements and choices done to achieve the goal in real world scenario;
• Session must be followed by a discussion on the presented choices: the speaker must be ready o be criticized

Hurry up!

The event will be hosted by the “Banca di Credito Cooperativo” in Treviglio (BG) and as all the community events will be free.

.m

Community Days 2012

Once again I had the pleasure to speak at one of the greatest Italian event: Community Days 2012.

I gave a talk speaking about that wonderful piece of code that NServiceBus is, it has been a real pleasure, thanks everyone for been there and a special thank to the organizers of the event for their perfect job and to Microsoft for hosting us.

Are you ready for the next step?

.m

Sad truth…

I was reading this: http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html, and this specific sentence make me sad:

“…I initially resisted this as overkill, except for obvious targets like email (…) and banking….”

I thought at the Italian situation where “Banking” is not so obvious…what a pain.

.m

RavenDB: storing data

Before going on with these series of introduction posts on RavenDB I suggest you to give a look at the excellent work that my dear friend Gian Maria is doing.
We have seen how to “install” RavenDB and how to read data, well…one way to read data: there are lot of options we’ll dive in the near future. Now it’s time to see how to store data in the database, what are the basic concepts behind RavenDB storage engine and some “tricks” to achieve all what you want.
Let’s do something interesting…

var personId = "";
 
using( var session = store.OpenSession() )
{
 var person = Person.CreateNew( "Mauro", "Servienti" );
 
 session.Store( person );
 session.SaveChanges();
 
 personId = session.Advanced.GetDocumentId( person );
}

We create a new Person (we’ll see in a minute Person class peculiarities) and simply store it in the database, trivial. We also do one interesting thing we ask to the database to get back the stored person identifier.
if we take a look at the data we find something like the following:

Figure: RavenDB data displaying 2 documents.
Where the “green” document is the person recently saved and the “blue” one the system document that keeps track of the generated identifiers…the name of the document (Hilo) should be familiar to NHibernate developers.
The key point here is that we have not assigned an identifier to the Person instance, but the database did it for us. This is due to a set of conventions that drives some of the RavenDB behavior, the Person class is defined in the following manner:

public class Person
{
 public static Person CreateNew( String firstName, String lastName )
 {
  return new Person()
  {
   FirstName = firstName,
   LastName = lastName
  };
 }
 
 [JsonConstructor]
 private Person()
 {
 
 }
 
 public String Id { get; private set; }
 public String FirstName { get; private set; }
 public String LastName { get; private set; }
}

There are lots of things to notice:

• The class has e read-only “Id” property, the convention is: if the class has a property named Id consider it to be the document identifier (the primary key), if it is null, string empty or a string that ends with “/” append a new identifier;
• The class has a private default constructor decorated with the JsonConstructor attribute whose role is to tell to the json serializer which is the constructor to use to deserialize the document (it is required only if there are no parameter-less constructors);
  • Have I told that everything is stored in the database as a document in the database?
• In future posts we’ll see why I have decided to expose FirstName and LastName property both as read-only, currently trust me…it just works;

With the generated person identifier in our hands we can go back to the database and ask for the stored document:

using( var session = store.OpenSession() )
{
 var person = session.Load<Person>( personId );
}

Here we can observe another way of loading data, the Load<T> method: the load method expects an identifier (or a set of identifiers) and goes directly to the database, bypassing the indexing engine, and loads the requested document(s), if a document cannot be found null is returned to the caller.
The keywords are: bypassing the indexing engine (indexing is covered in the next post).
Document Shape
Keep in mind that the database is very flexible and does not impose any requirement on the data shape and design, as we have seen we can use attributes to “drive” the json serializer toward its goal. We’ll discover that document databases suggest a preferred shape for data, shape that can you drive to success.
.m

What am I learning from the document database experience?

I’ve recently worked on a really interesting project based on RavenDB and NServiceBus, there will be a lot of time to deeply speak about it.

This argument should be treated at least in a 1h talk or far better in an open panel discussion…if someone is interested ping me, we can do that!

Document databases perfectly suites some DDD principles, such as the concept of aggregate; be aware that I’m not saying that relational databases does not suite, this post is not about relational versus document (I dislike the “no-sql” name).

Read on…questions

After the “document-db” experience I asked myself one single question: why do I need an ORM?
The short answer is: we tend to introduce an ORM to solve a problem that we have introduced.
So…if we do not introduce the first problem do we need an ORM anymore? basically yes, but now the question “moves” to: what an ORM should do for us?
The short answer is in the name: ORM –> map relational data to objects (period).


Abuse

ORM(s) per se are a wonderful thing, as with everything, problems come with the abuse of the wonders …typically what I hear from the field is something like: “I want to get rid of all that SQL strings that pollute my code”…
…and? they end up using hql strings with NHibernate…what is the difference? why the hell you want to hide SQL code from your program and then you want to view the generated SQL using a profiler?
I suppose, well at least it is what generally happens to me, that when we face the design of the database we tend to forget which will be, at the application level, the usage of the data we are designing…we tend to follow design guidelines and design rules instead of saying “I need the data in that shape, period”…and then we masturbate that data with an ORM to shape the perfectly normalized data in the form we really want them…

Astute…isn’t it?

Listen to me: give it up! try once to go back to the origin, use SQL, use Stored Procedures, design your data as you need them not as the book told you to design them…once you re-learned the “story” do you own choice, there are ton of tools out there that follows the “keep it simple, Luke” pattern:

• Dapper;
• PetaPoco;
• Simple.Data;
• Massive;

Conclusion(s)

I suppose that the human kind is basically stupid and tends to forget too easily the past…”they” gave us SQL, then someone invented the ORM (I’ll repeat myself: a wonder, really) and we forgot that the ORM is basically a way to get rid of the SQL it is not a “replacement”, then ORM guys start to over-engineer giving us lot’s of features on top of ORM(s)…features that, if you use an Object Model, can be really lifesavers such as Identity Map or Unit of Work but gave us also the vacuum cleaner that let us hide under the carpet bad data design decisions…and obviously we start to use all that cool features…producing tons of joins or select n+1 and looking at SQL, yeah old hated SLQ hidden under the carpet, in a profiler to understand what is going on…why the hell our application is so slow…
Give a try to document databases, not because they are better than relational ones (they are not, both have pros and cons) but because they force your mind to go back to the basics, they force you to understand some DDD principles (such as Aggregates and Bounded Contexts) and they let us see the light at the and of the tunnel giving us the opportunity to completely re-think our approach to the relational model.

.m

UGIAlt.Net

I would like to thank all the guys at the UGIAlt.Net user group for the amazing conference held in Milan where I gave a talk about RavenDB:

You can find the slide deck and samples on SkyDrive and the talk recording on Vimeo.

.m

Community Days 2012

Community Days 2012 are approaching, I’m excited because I’m going to give a talk about NServiceBus in real, real real , scenario.

See you there.

.m

Interesting Roslyn usage(s)

take a look here, really interesting…really.

.m

RavenDB: first contact

We have seen how to setup the development environment to use RavenDB, obviously the next step is to try to use our brand new environment.

NuGet to the rescue

First of all let’s setup the Visual Studio project to use RavenDB, using nuget as simple as adding a package reference to the RavenDB nuget package:

Figure: nuget installation dialog

the package installation downloads all the required dependencies and setup the application configuration file with the required connection string, that obviously must be adapted to your environment:

Figure: the application configuration file customized for my environment, where RavenDB server listen on port 81

The basics

RavenDB has 2 main building block that must be understood in order to manage all the features, having had previous experience with NHibernate can help in this area because the RavenDB API has been designed to help ORM users to migrate and stay in well known environment.

IDocumentStore

The IDocumentStore interface is the counterpart, for ORM users, of the NHibernate ISessionFactory there should (we’ll see in future posts why “should” and not must) be one document store per each RavenDB server we need to access.

Figure: the creation and initialization of the document store

the document store has several properties that we can use to customize the behavior of the connection, the security and the behavior of the store itself.

The only really required thing to do is to initialize, once, the store calling the quite obvious “Initialize” method.

IDocumentSession

the document session interface, that mimics the NHibernate ISession behaviors, is the entry point to access data stored on a RavenDB server instance. The document session is also our “Unit Of Work” implementation that let us manage business transactions against the server.

Connection to a database is as easy as:

Figure: the creation of a document session

where “myMusic” is the name of the database where I created the sample data, if we do not specify the database name the connection will be made against the default database (that always exists) or against the default database specified before the document store initialization using the DefaultDatabase property (we can also specify the default database in the connection string.

So far so good…so what?

…let’s try to pick some data…just try:

Figure: some data retrieved in a rather funky way

Cool! what’s going on? we have done a really strange thing we have used the generic Query method, closed against a .net 4.0 dynamic type, asking for the first 10 items…and we received back 10 items…not so expected as it can seem at a first look.

A little digression…little, trust me…

In order to figure out what has happened when the above query has been executed we need to understand how data (document) are stored in a document database.

No tables here guys , the above linq query can be compared to the following, invalid, T-SQL statement:

select top 10 *
go

That obviously has no meaning in a relational world because lacks, al least, the “from <table-name>” clause. Document databases has the concept of collection that represents an homogeneous subset of data and in RavenDB the subset you want to query over is expressed by the .net generic type you choose for the Query method (it is not really true, but for the moment it’s good enough).

Let’s move on

If we take a look at the database using the Raven Management Studio we can see that there are 2 different collections: Albums and Genres.

Figure: collection contained in the database

Which is the easiest method to tell to the document session that we want to query the albums collection? remember easiest.

Just define an Album type with the same shape of the json document stored in the database

Figures: on the left side the Album type definition on the right side the json document that represents an album in the database

As you can see we have defined even complex types (AlbumGenre and AlbumArtist, we’ll have future posts to detail the concept of “relation”) that will be automatically mapped to the corresponding nested properties in the json document. One thing you may already have noticed is that the json document is the serialized version of the .net type.

Query

if we rewrite the above query using the Album type we fetch exactly 10 albums:

Figure: RavenDB query executed to retrieve 10 albums from the database

wundershon …but how can RavenDB “map” our .net type to its own internal representation? using one of the thousands of cool features that this database have: metadata.

Figure: the same document showing the metadata tab in the management studio.

each document has a set of extensible metadata attached to it and the important one in this case is the Raven-Entity-Name, the database engine utilizes a set of conventions to translate a .net type name to the so called “Raven tag name”:

Figure: using document store conventions to map .net type name to Raven tag name.

Enough for this post…next time is time for “storing data”

.m