Skip to content

What is Object-Document Mapping (ODM)?

Introduction

In this article, we will examine the working principles and main components of Object-Relational Mapping ("ODM") tools, their pros and cons, as well as example libraries.

ODM

ODM (Object-Document Mapping) is a technology that connects object-oriented programs to document-oriented databases (e.g., MongoDB). It allows developers to interact with the database using objects and classes in the code, automatically converting objects to database documents (e.g., in JSON format) and vice versa. ODM simplifies data management, validation, and manipulation, freeing developers from having to write database-level queries manually.

How does ODM work?

ODM works as a tool that links object-oriented code with a document-oriented database. The key stages of its operation include:

  1. Model creation: ODM allows developers to create classes (models) that represent collections in the database. Each class maps to a collection, and its attributes map to document fields. Models describe the expected data types and can include validation rules.
  2. Connecting to the database: ODM manages the connection to the database. Once the connection is established, it automatically converts program objects to documents (e.g., JSON in MongoDB) and back to objects when reading data. Developers don’t need to manually configure each query.
  3. Creating and saving objects: Developers create model objects in code. When an object is saved, ODM converts it into a document and inserts it into the database collection. This process includes automatic data validation before saving.
  4. Reading data: ODM provides methods for performing queries. Interactions with documents occur through an object API, allowing filtering, sorting, and retrieving data without the need to manually write complex queries. Retrieved data is converted back into Python objects.
  5. Updating data: Objects fetched from the database can be modified in the code. Once changes are made, the object is saved, and ODM automatically generates queries to update the corresponding documents in the database.
  6. Deleting data: ODM provides convenient methods for deleting data. A developer can delete an object or group of objects, and ODM converts this into a query to remove documents from the database.
  7. Data validation: ODM supports data validation before saving. This ensures that data saved in the database meets established rules (e.g., required fields, value ranges) and prevents invalid data from being written.

ODM simplifies interactions with document-oriented databases by automating tasks like query generation, data conversion between objects and documents, data validation, and transaction management. This allows developers to focus on application logic without delving into the complexities of database interactions.

Advantages and Disadvantages of ODM

Advantages of ODM:

  1. Simplifies development: Allows developers to work with the database through object-oriented code, making it more understandable and maintainable.
  2. Automatic data conversion: Reduces the risk of errors during manual object-to-document mapping and vice versa.
  3. Data validation: Provides mechanisms to validate data before saving, ensuring data integrity.
  4. Increases productivity: Reduces boilerplate code and speeds up development.
  5. Convenient methods for working with data: Provides high-level APIs for CRUD operations and complex queries.

Disadvantages of ODM:

  1. Decreased performance: The additional abstraction layer can slow down query execution.
  2. Limited access to specific database features: Not all unique features of the database may be accessible through ODM.
  3. Challenges with complex operations: For specialized queries, it may be necessary to bypass ODM or directly use drivers.
  4. Difficult to debug: The abstraction makes it harder to understand how queries are executed at the database level.
  5. Additional dependencies: Requires learning and maintaining an additional tool, which can increase the application’s size.

Differences between ORM and ODM:

  1. Database type:
    • ORM is intended for relational databases (e.g., MySQL, PostgreSQL, Oracle), where data is stored in tables with a fixed schema.
    • ODM is used with document-oriented databases (e.g., MongoDB, CouchDB), where data is stored as documents with flexible structures.
  2. Data structure:
    • ORM operates with tables, columns, and relationships between tables. It requires a clearly defined database schema.
    • ODM works with documents, which can have a non-fixed structure and nested data. The schema can be flexible or non-existent.
  3. Query language:
    • ORM converts object operations into SQL queries.
    • ODM converts object operations into document-oriented database queries, often in JSON format.
  4. Schema flexibility:
    • ORM requires database migrations when changing the data structure.
    • ODM allows changing document structures without migrations, thanks to the flexible schema.
  5. Relationships between data:
    • ORM supports complex relationships (one-to-one, one-to-many, many-to-many) and ensures data integrity through database constraints.
    • ODM usually does not support complex relationships at the database level; relationships are handled at the application level.
  6. Performance and scalability:
    • Relational databases (ORM) are better suited for complex transactions and queries requiring a high degree of data integrity.
    • Document-oriented databases (ODM) often provide better horizontal scalability and performance when dealing with large volumes of data.

Today, there are quite a few document-oriented databases. Each has its own ODM that allows you to work with the database using an object-oriented approach. As with relational databases, there is also a lower-level approach that allows you to work directly with the database without using high-level abstractions.

The most popular databases are:

  • MongoDB
  • Amazon DynamoDB
  • CouchDB

We won’t be able to cover each of them in detail; this is a rather broad topic requiring deep dives into specifics. Instead, I suggest considering a slightly different scenario.

Let’s imagine that you have an application that needs to work with both relational and document-oriented databases. Using the standard approach, you would use a tool that is suitable for each database. You would need extensive knowledge of these tools. But what if I told you that you could use one tool to work with both types of data?

This tool is called Amsdal Glue.