Database Reference
In-Depth Information
Once wehavethecodeinplace tohandle documents with orwithout the
short_description
field, we might choose to gradually migrate the collection in the background, while our ap-
plication is running. For instance, we might migrate 100 documents at a time:
def
def
add_short_descriptions
():
node_ids_to_migrate
=
db
.
nodes
.
find
(
{
'short_description'
: {
'$exists'
:
False
}})
.
limit
(
100
)
db
.
nodes
.
update
(
{
'_id'
: {
'$in'
:
node_ids_to_migrate
} },
{
'$set'
: {
'short_description'
:
''
} },
multi
=
True
)
Once the entire collection is migrated, we can replace our application code to load the node
by URL to omit the default:
def
def
get_node_by_url
(
url
):
node
=
db
.
nodes
.
find_one
({
'url'
:
url
})
return
return
node
Storage (In-)Efficiency of BSON
There is one major drawback to MongoDB's lack of schema enforcement, and that is storage
efficiency. In a RDBMS, since all the column names and types are defined at the table level,
this information does not need to be replicated in each row. MongoDB, by contrast,
doesn't
know, at the collection level, what fields are present in each document, nor does it know their
types, so this information must be stored on a per-document basis. In particular, if you are
storing small values (integers, datetimes, or short strings) in your documents and are using
long property names, then MongoDB will tend to use a much larger amount of storage than
an RDBMS would for the same data. One approach to mitigating this in MongoDB is to use
short field names in your documents, but this approach can make it more difficult to inspect
the database directly from the shell.
Object-Document Mappers
One approach that can help with storage efficiency
and
with migrations is the use of a
MongoDB object-document mapper (ODM). There are several ODMs available for Python,
including MongoEngine, MongoKit, and Ming. In Ming, for example, you might create a
“Photo” model as follows:
