Renamed the dbshard module to schemarouter.

Documentation-Contents.md

@@ -51,7 +51,7 @@
 
 ## Routers
 
- - [DBShard Router](routers/dbshard/DBShard.md)
+ - [SchemaRouter Router](routers/schemarouter/SchemaRouter.md)
 
 ## Design Documents
 

routers/schemarouter/SchemaRouter-technical.md

@@ -1,12 +1,12 @@
-#DBShard Router - Technical Overview
+#SchemaRouter Router - Technical Overview
 
 This document is designed with a developer's point-of-view in mind. It explains the lifecycle of the module and details about its internal workings. It refers to the source code which can be found at [GitHub](https://github.com/mariadb-corporation/MaxScale).
 
 ## Source Files and Data Structures
 
-The dbshard router consists of the dbshard.h header file located in the `server/modules/include/` directory and the dbshard.c file located in the `server/modules/routing/dbshard` directory. This router implements the router interface defined in the router.h file. The entry points and structures this router uses can be found in the header file. The two main structures in use are the router instace and router session structures. The router instance structure is defined in `struct router_instance` and the router session structure in `struct router_client_session`.
+The schemarouter router consists of the schemarouter.h header file located in the `server/modules/include/` directory and the schemarouter.c file located in the `server/modules/routing/schemarouter` directory. This router implements the router interface defined in the router.h file. The entry points and structures this router uses can be found in the header file. The two main structures in use are the router instace and router session structures. The router instance structure is defined in `struct router_instance` and the router session structure in `struct router_client_session`.
 
-The definitions of the external functions and all the internal functions of the router can be found in the dbshard.c file.
+The definitions of the external functions and all the internal functions of the router can be found in the schemarouter.c file.
 
 ## Router Lifecycle
 
@@ -20,4 +20,4 @@ If a response is received the clientReply function is called and response is sim
 
 After the session ends the closeSession is called where the session is set to a closed state after which the freeSession is called where the final freeing of memory is done. After this point the router's session has gone through all the stages of its lifecycle.
 
-![DBShard Router Lifecycle](dbshard-lifecycle.png)
+![SchemaRouter Router Lifecycle](schemarouter-lifecycle.png)

routers/schemarouter/SchemaRouter.md

@@ -1,14 +1,14 @@
-#DBShard Router
+#SchemaRouter Router
 
-The DBShard router provides an easy and manageable sharding solution by building a single logical database server from multiple separate ones. Each database is shown to the client and queries targeting unique databases are routed to their respective servers. In addition to providing simple database-based sharding, the dbshard router also enables cross-node session variable usage by routing all queries that modify the session to all nodes.
+The SchemaRouter router provides an easy and manageable sharding solution by building a single logical database server from multiple separate ones. Each database is shown to the client and queries targeting unique databases are routed to their respective servers. In addition to providing simple database-based sharding, the schemarouter router also enables cross-node session variable usage by routing all queries that modify the session to all nodes.
 
 ## Configuration
 
-Here is an example configuration of the dbshard router:
+Here is an example configuration of the schemarouter router:
 
      [Shard Router]
      type=service
-     router=dbshard
+     router=schemarouter
      servers=server1,server2
      user=myuser
      passwd=mypwd
@@ -29,7 +29,7 @@ This would in effect allow the user 'john' to only see the database 'shard' on t
 
 ## Limitations
 
-The dbshard router currently has some limitations due to the nature of the sharding implementation and the way the session variables are detected and routed. Here is a list of the current limitations.
+The schemarouter router currently has some limitations due to the nature of the sharding implementation and the way the session variables are detected and routed. Here is a list of the current limitations.
 
 - Cross-database queries (e.g. SELECT column FROM database1.table UNION select column FROM database2.table) are not supported and are routed either to the first explicit database in the query, the current database in use or to the first available database, if none of the previous conditions are met.
 
@@ -39,9 +39,9 @@ The dbshard router currently has some limitations due to the nature of the shard
 
 - SELECT queries that modify session variables are not currently supported because uniform results can not be guaranteed. If such a query is executed, the behavior of the router is undefined. To work around this limitation the query must be executed in separate parts.
 
-- Currently the dbshard router does not support connecting directly to a sharded database.
+- Currently the schemarouter router does not support connecting directly to a sharded database.
 
-- Queries targeting databases not mapped by the dbshard router but still exist on the database server are not blocked but routed to the first available server. This possibly returns an error about database rights instead of a missing database. The behavior of the router is undefined in this case.
+- Queries targeting databases not mapped by the schemarouter router but still exist on the database server are not blocked but routed to the first available server. This possibly returns an error about database rights instead of a missing database. The behavior of the router is undefined in this case.
 
 ## Examples
 
@@ -49,4 +49,4 @@ To be implemeted.
 
 ## Technical Documentation
 
-[Technical Overview and Lifecycle Walkthrough](DBShard-technical.md)
+[Technical Overview and Lifecycle Walkthrough](SchemaRouter-technical.md)