Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Formatting fixes in README files.

  • Loading branch information...
commit db50265a0b5acb574e438687544c12b02c80fe0b 1 parent ffa8aff
@malcolmt authored
View
28 README.rst
@@ -19,17 +19,17 @@ There are a few good reasons a system might want to interact regularly with
multiple databases. “Because it’s what cool people do” is not one of those
reasons. Most multi-database usages often fall into one of three main classes:
- Separation by function.
- All data of one type in one database, all data of another type in some
- other database.
+Separation by function.
+ All data of one type in one database, all data of another type in some
+ other database.
- Data replication (separation by access)
- Some pieces of data are synchronized to multiple machines. Writes might
- go into one or more masters and reads normally come from the slaves.
+Data replication (separation by access)
+ Some pieces of data are synchronized to multiple machines. Writes might go
+ into one or more masters and reads normally come from the slaves.
- Separation by sharding.
- Data of a particular type (e.g. user records) is split across multiple
- databases, each database holding a shard of the whole data.
+Separation by sharding.
+ Data of a particular type (e.g. user records) is split across multiple
+ databases, each database holding a shard of the whole data.
Obviously, combinations of these classes are possible, such as replicated
sharded data in a huge site. There are tricks and traps to the way a developer
@@ -44,8 +44,8 @@ Code Layout
Each of the directories below this one has sample code for one of the above
situations. Each case is a self-contained Django project. Follow the individual
-`README.rst` instructions to create and populate the databases in each case. By
-default, I am using the SQLite, but there is nothing database-specific about
+``README.rst`` instructions to create and populate the databases in each case.
+By default, I am using the SQLite, but there is nothing database-specific about
the code, so feel free to change the ``ENGINE`` setting for one or more
databases and see what happens (there's no requirement in Django that each
database uses the same backend).
@@ -53,9 +53,9 @@ database uses the same backend).
If you want to browse / test the code in order of increasing complexity, I
would recommend the following order:
- * functional_split
- * access_split
- * sharding
+* functional_split
+* access_split
+* sharding
Good Luck!
View
8 access_split/README.rst
@@ -4,10 +4,10 @@
This is the second of three examples of multiple database use. In this example,
the initial setup is extended to add a second database for reviews that is used
-for read-only access. All writes go to the main (*"reviews"*) database, whilst
-reads come from the shadow (*"reviews-s"*) database.
+for read-only access. All writes go to the main (*reviews*) database, whilst
+reads come from the shadow (*reviews-s*) database.
-All product information is still in the main (*"default"*) database, as before.
+All product information is still in the main (*default*) database, as before.
Setup
======
@@ -20,7 +20,7 @@ times::
python manage.py syncdb --database reviews-s
An admin user will be created from an initial data fixture. Both the username
-and password for this user are *"admin"* (without the quotes).
+and password for this user are *admin* (without the quotes).
Trying out the code
====================
View
4 functional_split/README.rst
@@ -3,7 +3,7 @@
=================================================
In this example, the two main application models are in different databases.
-All products are in the main ("default") database, whilst product reviews are
+All products are in the main (*default*) database, whilst product reviews are
in the "reviews" database.
Setup
@@ -15,7 +15,7 @@ To create the example databases, you need to run the ``syncdb`` command twice::
python manage.py syncdb --database reviews
An admin user will be created from an initial data fixture. Both the username
-and password for this user are *"admin"* (without the quotes).
+and password for this user are "*admin*" (without the quotes).
Trying out the code
====================
View
12 sharding/README.rst
@@ -4,14 +4,14 @@
This is the third of three examples of multiple database use. In this example,
the initial setup is extended to add three databases for reviews
-(*"reviews-1"*, *"reviews-2"*, *"reviews-3"*). Review records are stored in one
+(*reviews-1*, *reviews-2*, *reviews-3*). Review records are stored in one
of these databases, based on a hash of their primary key value. In large-scale
production environments, this would distribute the read and write load evenly
across a large database cluster. It could also be further combined with
database replication and read-only slave databases for separate read and write
loads.
-All product information is still in the main (*"default"*) database, as before.
+All product information is still in the main (*default*) database, as before.
Setup
======
@@ -25,7 +25,7 @@ times::
python manage.py syncdb --database reviews-3
An admin user will be created from an initial data fixture. Both the username
-and password for this user are *"admin"* (without the quotes).
+and password for this user are "*admin*" (without the quotes).
Trying out the code
====================
@@ -42,11 +42,11 @@ behind the scenes.
Reviews are immediately viewable to everybody after being created (in contrast
to the second simulated example). However, they are distributed more or less
evenly (in the long run) across the three databases. You can see this by using
-the SQLite command line client to examine the `reviews_review` table in each of
-the *reviews-X* databases.
+the SQLite command line client to examine the ``reviews_review`` table in each
+of the *reviews-X* databases.
At the present time, the admin interface only displays review results from the
-*"reviews-1"* database.
+*reviews-1* database.
Development exercise
---------------------
Please sign in to comment.
Something went wrong with that request. Please try again.