add some more docs

docs/migration.md

@@ -52,9 +52,16 @@ If you are making calls to the event store yourself, take a look at the event_st
 ## DB migrations
 
 If you are using v6 with MySQL (using doctrine adpater) and you want to switch to v7 with MySQL (using pdo-event-store),
-you need to upgrade your database before you do this. The way events are persisted have changed and you cannot simply
-update your source code to make this change. You need to write a migration script, take the database offline,
-perform the migration and go back online.
+you need to upgrade your database before you do this (same for other db vendors of course). The way events are
+persisted have changed and you cannot simply update your source code to make this change. You need to write a migration
+script, take the database offline, perform the migration and go back online.
+
+Things to do to migrate:
+- Read all events
+- Update event metadata
+- Persist the event back to a new stream created with v7
+
+This would need to be done for all event streams.
 
 As this is a very tough job, we don't provide any migration script currently and for some applications a downtime is not
 acceptable, then v7 might not be the right choice for you, use it when you can take the application offline for a while

docs/projections.md

@@ -4,6 +4,10 @@ New in v7 are queries and projectons.
 
 ## Queries
 
+We are talking here about event store queries, not queries on your read model. An event store query reads one or
+multiple event stream, aggregates some state from it and makes it accessible. A query is non-persistent, will only
+get executed once, return a result, and that's it.
+
 To get started, let's take a simple example where we want to query the
 event-store, how often a given user has changed his username.
 
@@ -55,6 +59,10 @@ $query
     ->run();
 ```
 
+Queries can be used to answer a given question easily, because you don't need to figure out in which read model the
+data is present (maybe it's not?) and how to query it there (maybe a lot of joins are needed in RDBMS).
+Also you can do temporal queries very easy, which is hard until impossible to do with any other database system.
+
 ## Projections
 
 Projections are like queries, but first of all, they are persistent, the created state is persistent and can be queried