Mongoose: ¿Es posible completar sin `_id`?

Creado en 26 dic. 2014  ·  82Comentarios  ·  Fuente: Automattic/mongoose

Revisé la API http://mongoosejs.com/docs/populate.html y probé. Parece que populate solo puede funcionar en _id extranjeros. Incluso hay una opción match , solo agrega más condiciones de filtrado en la condición de consulta _id . No hay forma de rellenar campos que no estén relacionados con _id .

En mi proyecto, mantenemos _id como ObjectId y tiene otro campo como Número de incremento automático. Por ejemplo, el modelo customers tiene _id como Objeto y cuid como número incremental. Otras colecciones solo hacen referencia a cuid no a _id .

¿Sería genial poder personalizar esto?
¿Hay alguna limitación de diseño que provoque que falte esta función?

enhancement

Comentario más útil

@rturk Realmente me gusta mucho ese complemento, gracias por señalarlo. @alexmingoia, ¿cuáles son sus pensamientos sobre: ​​fusionar su módulo en el núcleo de mangosta? La idea de usar virtuals para manejar una población más genérica (sin tener un campo real persistente en la base de datos) es realmente poderosa.

Todos 82 comentarios

Sería genial poder personalizar esto, pero en este momento aplicamos _id . Sin embargo, no puedo pensar en una buena razón en mi cabeza por la que no. Tendré que investigar más.

La capacidad de completar no solo en un solo campo, sino incluso en un conjunto de campos, es casi necesaria para admitir correctamente la fragmentación, que es un gran caso de uso para nosotros.

Por ejemplo, tenemos una colección "estudiantes" que puede tener una clave de fragmento para "suscripción"; cuando completamos los datos de los estudiantes de nuestro modelo de secciones (que contiene una matriz de estudiantes), tenemos la suscripción en el documento, pero solo buscará en función del _id almacenado en "estudiante" en lugar de permitirnos especificar que también debe mapear el campo "asignación" de los documentos a "asignación" en el estudiante.

Dado que entonces estaríamos haciendo una búsqueda sin la clave de fragmento cuando se completa, hace que el fragmento sea inútil, lo que requiere que se golpeen todos los fragmentos para recuperar los datos en lugar de solo uno.

Esto es algo para lo que estaríamos dispuestos a financiar el desarrollo o incluso a hacerlo nosotros mismos si pudiéramos obtener alguna orientación sobre dónde hacer el trabajo. Es una necesidad importante para nuestra empresa (GradeCam).

@taxilian, ¿está configurando la opción de esquema shardKey ? AFAIK para eso es esa opción.

En realidad, aún no me he movido para comenzar a hacerlo porque he estado buscando una solución a este problema; ¿Rellena tiene en cuenta shardKey? Mi entendimiento fue que shardKey solo afectó actualizaciones e inserciones

Sería genial poder especificar el campo al que se "unirá", por ejemplo, me gustaría poder completar no solo por el campo de ID de usuario (es decir, _id) sino también por tipo de usuario, grupo de usuarios, etc.
¡Gracias!

+1

+1 sería muy útil

+1 lo mismo aquí!

+1 me encanta tener esto

+1

+1

+1

Sería especialmente bueno poder seleccionar la variable con la que le gustaría completar agregando un parámetro como key :

Por ejemplo, si tuviera publicaciones en las que quisiera completar los parámetros author y comments , pero los parámetros contienen parámetros que no son de ObjectId (nombre de usuario del usuario y título de los comentarios) antes de completar:

{
author: "user1",
comments:["comment5", "comment6"],
title:"Post1"
}

Sería bueno poder agregar un parámetro como "clave" para que Mongo sepa qué parámetro buscar:

Posts.find().populate([{path:"author", model:"Users", key:"username"}, {path:"comments", model:"Comments", key:"title"}])

Esto llenaría el parámetro author con un usuario encontrado por nombre de usuario, así como también llenaría el parámetro comments con comentarios encontrados por su título (me doy cuenta de que los comentarios por título son un poco poco realistas, pero obtienes el punto).

+1

+1

+1

+1

+1

+1

+1

Gran acuerdo. Me encantaría poder definir esquemas de población personalizados. Sería excelente para cualquier esquema con uno o más campos que sean rutas de archivos, lo que permite completar para leer desde el almacenamiento.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Pruebe este código: https://github.com/alexmingoia/mongoose-populate-virtuals.

En realidad, ¿algún motivo para no fusionar el código de Alex en el repositorio principal y convertirlo en una función central?

@rturk Realmente me gusta mucho ese complemento, gracias por señalarlo. @alexmingoia, ¿cuáles son sus pensamientos sobre: ​​fusionar su módulo en el núcleo de mangosta? La idea de usar virtuals para manejar una población más genérica (sin tener un campo real persistente en la base de datos) es realmente poderosa.

Eso sería ideal. Sería mucho mejor en el núcleo porque sobrecarga Query.prototype.populate y otras funciones del núcleo.

Lo único que me impide crear una solicitud de extracción es que hay poca o ninguna cobertura de prueba y falta documentación. Lo estoy usando en producción en múltiples escenarios y es estable, pero creo que si alguien escribiera un conjunto de pruebas, podría exponer algunos problemas menores o idiosincrasias que deben documentarse.

¿Alguien está dispuesto a abordar el conjunto de pruebas? Si no, puedo hacerlo, pero no espere que llegue antes del próximo mes.

Le daré un vistazo. He tenido la intención de reescribir poblar de todos modos :)

Pídeme un ping en IRC (freenode, amingoia ) o gitter si tienes alguna pregunta sobre el código.

https://github.com/whitecolor/mongoose-fill también hace un gran trabajo para completar el uso de datos de otros modelos

+1

+1

+1

es un requisito :)

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+3

+1

¿Fue útil esta página
0 / 5 - 0 calificaciones