Mongoose: É possível preencher sem `_id`?
Eu verifiquei a API http://mongoosejs.com/docs/populate.html e experimentei. Parece que populate só funciona em _id estrangeiros. Mesmo que haja uma opção match , basta adicionar mais condições de filtragem na condição de consulta _id . Não há como apenas preencher com campos não envolvidos com _id .
No meu projeto, mantemos o _id como ObjectId e temos outro campo como número de incremento automático. Por exemplo, o modelo customers tem _id como Objeto e cuid como número incremental. Outras coleções apenas fazem referência a cuid não a _id .
Seria ótimo poder personalizar isso?
Existe alguma limitação de design causando a falta desse recurso?
mocheng
Todos 82 comentários
Seria ótimo poder personalizar isso, mas agora aplicamos _id . Eu não consigo pensar em uma boa razão de cabeça para que não. Vou ter que investigar mais.
vkarpov15
em 1 jan. 2015
A capacidade de preencher não apenas em um único outro campo, mas até mesmo em um conjunto de campos, é quase necessária para oferecer suporte adequado à fragmentação, o que é um grande caso de uso para nós.
Por exemplo, temos uma coleção "alunos" que pode ter uma chave de fragmentação para "assinatura"; quando preenchemos os dados do aluno de nosso modelo de seções (que contém uma matriz de alunos), temos a assinatura no documento, mas ela só pesquisará com base no _id armazenado em "aluno" em vez de nos permitir especificar que ele também deve mapear o campo "tarefa" dos documentos para "tarefa" no aluno.
Como estaríamos fazendo uma pesquisa sem a chave de fragmentação ao preencher, isso torna a fragmentação inútil, exigindo que todos os fragmentos sejam atingidos para recuperar os dados em vez de apenas um.
Isso é algo para o qual estaríamos dispostos a financiar o desenvolvimento ou até mesmo fazer nós mesmos se pudéssemos obter alguma orientação sobre onde fazer o trabalho. É uma grande necessidade para nossa empresa (GradeCam).
taxilian
em 20 fev. 2015
@taxilian você está configurando a opção de esquema shardKey ? AFAIK é para isso que serve essa opção.
vkarpov15
em 20 fev. 2015
Na verdade, ainda não comecei a fazer isso porque estou procurando uma solução para esse problema; o populate leva em conta o shardKey? Meu entendimento era que shardKey afetava apenas atualizações e inserções
taxilian
em 20 fev. 2015
Seria ótimo poder especificar o campo que deve ser "unido por", por exemplo, eu gostaria de poder preencher não apenas pelo campo userId (ou seja, _id), mas também por userType, userGroup etc.
Obrigado!
arliber
em 19 abr. 2015
+1
podoler
em 19 abr. 2015
+1 seria muito útil
nadavsinai
em 30 abr. 2015
+1 mesmo aqui!
xr
em 9 mai. 2015
+1 adoro ter isso
prakash122
em 21 mai. 2015
+1
ricolo
em 24 mai. 2015
+1
vlapo
em 4 jun. 2015
+1
Seria especialmente bom poder selecionar a variável com a qual você gostaria de preencher adicionando um parâmetro como key :
Por exemplo, se tivesse posts que eu quisesse preencher os parâmetros author e comments , mas os parâmetros estão mantendo parâmetros não ObjectId (nome de usuário do usuário e título dos comentários) antes da população:
{
author: "user1",
comments:["comment5", "comment6"],
title:"Post1"
}
Seria bom poder adicionar um parâmetro como "key" para permitir que o mongo saiba qual parâmetro pesquisar:
Posts.find().populate([{path:"author", model:"Users", key:"username"}, {path:"comments", model:"Comments", key:"title"}])
Isso preencheria o parâmetro author com um usuário encontrado por nome de usuário, bem como preencheria o parâmetro comments com comentários encontrados por seu título (eu percebo que os comentários por título são um pouco irreais, mas você obtém o ponto).
prescottprue
em 8 jun. 2015
+1
apankov
em 10 jun. 2015
+1
marklar21
em 14 jul. 2015
+1
john-bower
em 31 jul. 2015
+1
jack-guy
em 10 ago. 2015
+1
asafam
em 23 ago. 2015
+1
whyhankee
em 25 ago. 2015
+1
ArcoMul
em 25 ago. 2015
Grande concordo. Eu adoraria a capacidade de definir esquemas de população personalizados. Seria ótimo para qualquer esquema com um ou mais campos que são caminhos de arquivo, permitindo que o preenchimento seja lido do armazenamento.
cannonpalms
em 3 set. 2015
+1
raphaelokon
em 11 set. 2015
+1
naoxink
em 14 set. 2015
+1
manasb-uoe
em 7 out. 2015
+1
Poplava
em 9 out. 2015
+1
lfk
em 20 out. 2015
+1
RithwikAnand
em 31 out. 2015
+1
justvisiting
em 6 nov. 2015
+1
kumasento
em 13 nov. 2015
+1
BentoumiTech
em 14 nov. 2015
+1
loris
em 17 nov. 2015
+1
tomerb15
em 18 nov. 2015
+1
keithl8041
em 20 nov. 2015
+1
danielflippance
em 22 nov. 2015
+1
prabhupadas
em 24 nov. 2015
+1
leonardokl
em 17 dez. 2015
+1
robjens
em 18 dez. 2015
+1
beinnova
em 21 dez. 2015
+1
MangeshPimpalkar
em 24 dez. 2015
+1
roygwsidev
em 2 jan. 2016
+1
docksteaderluke
em 12 jan. 2016
+1
wohugb
em 15 jan. 2016
+1
joshbeam
em 25 jan. 2016
+1
pavan612
em 28 jan. 2016
+1
kennethkoontz
em 30 jan. 2016
+1
R0R0N0A
em 4 fev. 2016
+1
liraniom
em 9 fev. 2016
+1
Pyo25
em 11 fev. 2016
+1
danilvalov
em 17 fev. 2016
Tente este código: https://github.com/alexmingoia/mongoose-populate-virtuals.
Na verdade, algum motivo para não mesclar o código de Alex no repositório principal e tornar isso um recurso central?
rturk
em 18 fev. 2016
@rturk Eu realmente gosto desse plugin, obrigado por apontá-lo. @alexmingoia quais são seus pensamentos sobre: mesclar seu módulo no núcleo do mangusto? A ideia de usar virtuais para lidar com populações mais genéricas (sem ter um campo real persistido no banco de dados) é realmente poderosa.
vkarpov15
em 18 fev. 2016
Isso seria o ideal. Seria muito melhor no núcleo porque sobrecarrega Query.prototype.populate e outras funcionalidades do núcleo.
A única coisa que me impede de criar uma solicitação pull é que há pouca ou nenhuma cobertura de teste e falta documentação. Estou usando-o em produção em vários cenários e é estável, mas acho que se alguém escrevesse um conjunto de testes, isso poderia expor alguns problemas menores ou idiossincrasias que precisam ser documentadas.
Alguém está disposto a enfrentar o conjunto de testes? Se não - eu posso fazer isso, mas não espere que chegue antes do próximo mês.
alexmingoia
em 18 fev. 2016
Vou dar uma olhada. Eu estava querendo reescrever preencher de qualquer maneira :)
vkarpov15
em 19 fev. 2016
Faça um ping no IRC (freenode, amingoia ) ou gitter se você tiver alguma dúvida sobre o código.
alexmingoia
em 19 fev. 2016
https://github.com/whitecolor/mongoose-fill também faz um ótimo trabalho para preencher usando dados de outros modelos
sibelius
em 28 fev. 2016
+1
BenSower
em 2 mar. 2016
+1
juanpujol
em 3 mar. 2016
+1
obengwilliam
em 9 mar. 2016
isso é um dever :)
gitawego
em 9 mar. 2016
+1
amit3vr
em 11 mar. 2016
+1
teja-paketts
em 18 mar. 2016
+1
stewwan
em 22 mar. 2016
+1
nguyentrongbang
em 26 mar. 2016
+1
ingoncalves
em 5 abr. 2016
+1
markotom
em 7 abr. 2016
+1
forksofpower
em 12 abr. 2016
+1
ashe540
em 17 abr. 2016
+1
BenBestmann
em 26 abr. 2016
+1
realbisoye
em 11 mai. 2016
+1
rychkog
em 13 mai. 2016
+1
atamas101
em 18 mai. 2016
+1
mogita
em 19 mai. 2016
+1
samidarko
em 20 mai. 2016
+1
zing777
em 7 jun. 2016
+1
oguzhanaslan
em 28 jun. 2016
thatisuday
em 20 jul. 2016
+1
atakangktepe
em 6 out. 2016
+1
anaibol
em 26 out. 2016
+1
teemuniiranen
em 17 fev. 2017
+1
coderafei
em 2 mar. 2017
+1
fbegue
em 26 mar. 2017
+3
anaibol
em 31 mar. 2017
+1
omarps
em 16 jun. 2017
Questões relacionadas
ghost
·
3Comentários
lukasz-zak
·
3Comentários
adamreisnz
·
3Comentários
adamreisnz
·
3Comentários
rohan-paul
·
3Comentários
Comentários muito úteis
@rturk Eu realmente gosto desse plugin, obrigado por apontá-lo. @alexmingoia quais são seus pensamentos sobre: mesclar seu módulo no núcleo do mangusto? A ideia de usar virtuais para lidar com populações mais genéricas (sem ter um campo real persistido no banco de dados) é realmente poderosa.