Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
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 tipo ORM (tipo mapping objeto-relacional) agregan funcionalidades como modelos y validación a PyMongo.

  • MincePy es un mapeador objeto-documento (ODM) diseñado para que cualquier objeto Python sea almacenable y consultable en una base de datos MongoDB. Se diseñó pensando en el aprendizaje automático y en aplicaciones de ciencia computacional y experimental de big data. Sin embargo, es completamente general y puede ser útil para cualquiera que busque organizar, compartir o procesar grandes cantidades de datos con el menor cambio posible en su flujo de trabajo actual.

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

  • MongoEngine te permite utilizar una sintaxis inspirada en el ORM de Django para definir esquemas de documentos y consultar colecciones.

  • 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 (Object Document Mapper) de MongoDB para Python que se creó para satisfacer dos necesidades: la falta de un ODM asincrónico y la dificultad para serializar documentos con otros ODM. uMongo funciona con varios controladores: PyMongo, TxMongo, motor_asyncio y mongomock. El código fuente está disponible en GitHub.

Esta sección enumera herramientas y adaptadores que han sido diseñados para funcionar con diversos frameworks y librerías 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 está en vista previa pública y se destina únicamente a fines de evaluación. No se recomienda el Public Preview para implementaciones de producción, ya que podrían introducirse cambios disruptivos. Para obtener más información, consulta Funciones de vista previa.

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

PyMongo utiliza funciones de subprocesos y sockets de la librería estándar de Python. Al usar gevent, PyMongo puede realizar entradas/salidas asíncronas con sockets no bloqueantes y programar operaciones en greenlets en lugar de hilos.

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

Cierra 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 elimine la referencia a cualquier objeto MongoClient activo antes de cerrar su aplicación. En algunos marcos de aplicaciones, puedes utilizar un controlador de señales para finalizar los greenlets en segundo plano cuando tu aplicación reciba 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 asegurarse de que su aplicación se ejecute en el intérprete Python principal del demonio, en lugar de un subintérprete. Esto evita un pequeño costo que se incurre 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 tu aplicación PyMongo:

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

Si tienes varias aplicaciones PyMongo, coloca 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 C de Python tienen problemas al ejecutarse en varios sub-intérpretes de Python. Estas dificultades están explicadas en la documentación de Py_NewInterpreter y en la sección Múltiples subinterpretadores de Python de la documentación de mod_wsgi.

Para obtener una lista de herramientas que pueden utilizar sugerencias de tipo para detectar errores en tu código, consulta Tipado estático con Python en la documentación del módulo typing.

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ás usando Mypy y quieres dejar de usar los tipos proporcionados, añade las siguientes líneas a tu archivo de configuración de Mypy:

[mypy-pymongo]
follow_imports = False

Esta sección enumera alternativas a PyMongo.

  • Motor es un controlador de MongoDB completo y no bloqueante para aplicaciones Python Tornado.

  • TxMongo es un driver asíncrono Twisted Python para MongoDB.

  • MongoMock es una pequeña librería para ayudar a probar 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