Docs Menu
Docs Home
/ /

Integraciones de terceros y herramientas

Esta página describe algunas bibliotecas de terceros populares para trabajar con PyMongo. A excepción de Motor, todas las bibliotecas de esta página son mantenidas por la comunidad. Para mantener esta lista actualizada, los proyectos que no se hayan actualizado recientemente se eliminarán ocasionalmente o se moverán al final.

Tip

Aunque estas bibliotecas pueden ser útiles, recomendamos que los nuevos usuarios de PyMongo comiencen trabajando directamente con el controlador. PyMongo por sí solo cubrirá las necesidades de la mayoría de los usuarios, y trabajar con él es ilustrativo del funcionamiento de MongoDB.

Las capas de tipo ORM (mapping relacional de objetos) agregan características como modelos y validación a PyMongo.

  • MincePy es un mapeador de objetos y documentos (ODM) diseñado para que cualquier objeto de Python sea almacenable y consultable en una base de datos MongoDB. Fue diseñado pensando en aplicaciones de aprendizaje automático, big data, computación y ciencias experimentales. Sin embargo, es completamente general y puede ser útil para cualquiera que busque organizar, compartir o procesar grandes cantidades de datos con la mínima modificación posible de su flujo de trabajo.

  • Ming es una biblioteca que permite aplicar esquemas a una base de datos MongoDB en una aplicación Python. Fue desarrollada por SourceForge durante su migración a MongoDB. Consulte la entrada de blog introductoria para obtener más información.

  • MongoEngine le permite utilizar una sintaxis inspirada en Django ORM para definir esquemas para documentos y colecciones de consultas.

  • MotorEngine es una adaptación de MongoEngine a Motor, que permite el acceso asíncrono con Tornado. Implementa las mismas API de modelado de forma portátil, lo que significa que un modelo definido en MongoEngine puede leerse en MotorEngine.

  • uMongo es un ODM de MongoDB para Python creado para satisfacer dos necesidades: la falta de un ODM asíncrono y la dificultad de serializar documentos con otros ODM. uMongo funciona con varios controladores: PyMongo, TxMongo, motor_asyncio y mongomock. El código fuente está disponible en GitHub.

En esta sección se enumeran herramientas y adaptadores que han sido diseñados para funcionar con varios marcos y bibliotecas de Python.

Puedes usar el backend oficial de Django MongoDB para usar MongoDB como base de datos en tus aplicaciones. Este backend utiliza PyMongo para conectarse a MongoDB. Con él, puedes usar modelos de Django para representar documentos MongoDB, con compatibilidad con formularios, validaciones y autenticación de Django. Además, te permite usar optimizaciones de consultas específicas de MongoDB en tus aplicaciones, como operaciones de agregación e índices.

Importante

Vista previa pública

El backend de Django MongoDB se encuentra en versión preliminar pública y su uso es solo para fines de evaluación. No se recomienda su uso en implementaciones de producción, ya que podrían introducirse cambios importantes. Para obtener más información, consulte Características de la versión preliminar.

En esta sección se enumeran las herramientas que admiten la interoperabilidad con otras herramientas.

PyMongo utiliza funciones de subprocesos y sockets de la biblioteca estándar de Python. Mediante gevent, PyMongo puede realizar E/S asíncronas con sockets no bloqueantes y programar operaciones en greenlets en lugar de subprocesos.

Para usar gevent con PyMongo, llame a gevent monkey.patch_all() método antes de cargar cualquier otro módulo, como se muestra en el siguiente ejemplo:

# You must call patch_all() *before* importing any other modules
from gevent import monkey
_ = monkey.patch_all()
from pymongo import MongoClient
client = MongoClient()

Importante

Cerrar MongoClient para evitar bloqueos

Si llama a monkey.patch_all() al iniciar su aplicación, MongoClient usará greenlets en lugar de hilos para supervisar el estado del servidor. Al apagar, si su aplicación llama al método ~gevent.hub.Hub.join() sin terminar primero estos greenlets, la llamada al método ~gevent.hub.Hub.join() se bloquea indefinidamente.

Para evitar esto, cierre o desreferencia cualquier objeto MongoClient activo antes de salir de la aplicación. En algunos frameworks de aplicaciones, puede usar un controlador de señales para finalizar los greenlets en segundo plano cuando la aplicación recibe SIGHUP, como se muestra en el siguiente ejemplo:

import signal
def graceful_reload(signum, traceback):
"""Explicitly close some global MongoClient object."""
client.close()
signal.signal(signal.SIGHUP, graceful_reload)

Este problema afecta a las aplicaciones que utilizan versiones de uWSGI anteriores a 1.9.16 o versiones más recientes con la -gevent-wait-for-hub opción. Para más información, consulte el registro de cambios de uWSGI.

El paquete mod_wsgi proporciona un módulo Apache que implementa una interfaz compatible con WSGI para alojar aplicaciones web basadas en Python en el servidor web Apache.

Para ejecutar su aplicación PyMongo bajo mod_wsgi, siga estas pautas:

  • Use la directiva WSGIDaemonProcess para ejecutar mod_wsgi en modo demonio. Si su configuración de mod_wsgi incluye solo la directiva WSGIScriptAlias, se ejecutará en modo integrado.

  • Utilice la directiva WSGIApplicationGroup %{GLOBAL} para garantizar que su aplicación se ejecute en el intérprete principal de Python del demonio, en lugar de en un subintérprete. Esto evita un pequeño coste al decodificar BSON en un subintérprete.

  • Utiliza la directiva WSGIProcessGroup para asignar cada aplicación a un demonio independiente. Esto garantiza que las aplicaciones no afecten el estado de las demás.

La siguiente configuración de mod_wsgi muestra cómo usar las directivas anteriores para ejecutar su aplicación PyMongo:

<VirtualHost *>
WSGIDaemonProcess my_process
WSGIScriptAlias /my_app /path/to/app.wsgi
WSGIProcessGroup my_process
WSGIApplicationGroup %{GLOBAL}
</VirtualHost>

Si tiene varias aplicaciones PyMongo, coloque cada una en un demonio separado en el grupo de aplicaciones global:

<VirtualHost *>
WSGIDaemonProcess my_process
WSGIScriptAlias /my_app /path/to/app.wsgi
<Location /my_app>
WSGIProcessGroup my_process
</Location>
WSGIDaemonProcess my_other_process
WSGIScriptAlias /my_other_app /path/to/other_app.wsgi
<Location /my_other_app>
WSGIProcessGroup my_other_process
</Location>
WSGIApplicationGroup %{GLOBAL}
</VirtualHost>

Nota

Muchas extensiones de Python C presentan problemas al ejecutarse con varios subintérpretes de Python. Estas dificultades se explican en la documentación de Py_NewInterpreter y en la sección "Múltiples subintérpretes de Python" de la documentación de mod_wsgi.

Para obtener una lista de herramientas que pueden usar sugerencias de tipo para detectar errores en su código, consulte Tipificación estática con Python en la typing documentación del módulo.

Nota

Los valores predeterminados para los tipos de documentos genéricos aún no están disponibles en Mypy. Para obtener información sobre las limitaciones de Mypy que causaron este problema, consulte el repositorio de Mypy en GitHub.

Si está utilizando Mypy y desea dejar de utilizar los tipos proporcionados, agregue las siguientes líneas a su archivo de configuración de Mypy:

[mypy-pymongo]
follow_imports = False

Esta sección enumera alternativas a PyMongo.

  • Motor es un controlador MongoDB completo y sin bloqueos para aplicaciones Python Tornado.

  • TxMongo es un controlador Twisted Python asincrónico para MongoDB.

  • MongoMock es una pequeña biblioteca que facilita la prueba de código Python. Utiliza PyMongo para interactuar con MongoDB.

Nota

PyMongo es incompatible con PythonAnywhere

PyMongo crea subprocesos de Python, algo que PythonAnywhere no admite.

Para obtener más información, consulte el ticket de Jira correspondiente.

Volver

TLS

En esta página