2012-12-19 2 views
1

사용자 문서의 소셜 미디어에서 친구를 캐싱하려고하고 저장/가져 오는 데 문제가 있습니다. 첫째, 나는 맹목적으로 친구들의 캐시를 벗겨 내고 새로운 데이터 가져 오기로 채울 것입니다.하지만이를 통해 모든 임베디드 문서가 모든 사용자들 사이에서 고유해야한다는 것을 알게되었습니다 (저는 친구가 몇 명 있습니다. 내 테스트 계정에 같은 내가 얻을 : I가 계획 때문에이에서 너무몽구스에서 기존 임베디드 문서 받기

{"name":"MongoError","err":"E11000 duplicate key error index: test-dev.users.$friends.outsideID_1 dup key: { : \"1205314313242\" }","code":11001,"n":0,"connectionId":274,"ok":1} 

내가이 포함 된 문서 내 다른 이미 등록 및 업데이트 계정에 존재하기 때문에 그 문서를 만들 수 있다는 사실을 알고 (outsideID는 인덱스 나중에 그것을 사용하여 검색)) 그런 다음 OutsideFriend.find ({ 'outsideID': {$ in : friendsIDs}} (friendsID는 SM 쿼리에서 가져온 ID의 배열 임) 등을 시도하기 시작했습니다. 콜백에서 나는 새로운 친구를 추가하고 단지 존재를 추가하려고 시도합니다. 문서를 문제의 사용자에게 보내서 시스템에서이 문서를 복제하려고 시도하지 않도록하십시오. 그러나 어떤 이유로 든 OutsideFrind.find()는 어떤 문서도 반환하지 않으므로 ... 임베디드 문서가 중앙 집중화되지 않는다고 생각하게 만듭니다. 그렇다면 첫 번째 시도가 실패하는 이유는 무엇입니까?

어떻게하면됩니까? (스키마 아래, 당신이 다른 어떤 정보를 필요로하는 경우 알려 주시기 바랍니다!)

현재 스키마 :

//External friend model                                                
var OutsideFriend = new Schema({ 
     outsideID:{type:String, index:true, unique:true} 
     ,username:String 
     ,location:String 
     ,avatarURL:String 
}); 

//User model                                                   
var User = new Schema({ 
     avatarURL:String 
     ,mySMID:String 
    //Social Media info                                                 
     ,smID:{type:String, index:true, unique:true} 
     ,tok:String 
     ,tokSec:String 
     ,friends:[OutsideFriend] 
}; 

답변

1

가 귀하의 질문에 어떤 일이 일어나고 많은,하지만 당신은 UserOutsideFriend 독립 조회하려는 경우, 그러면 모델을 User에 삽입해서는 안됩니다. 대신 친구에게 ObjectId 참조를 저장하고 populateUser에 저장하면됩니다. 일관성 문제를 야기 할 때까지 포함 된 복사본으로 조기에 최적화하지 마십시오.

그래서 User 모델로 변경합니다 :

이 이
var User = new Schema({ 
    avatarURL:String 
    //Social Media info 
    ,smID:{type:String, index:true, unique:true} 
    ,tok:String 
    ,tokSec:String 
    ,friends:[{type: ObjectId, ref: 'OutsideFriend'}] 
}; 
+0

음, 원래 아이디어는 사용자의 문서에 SM 친구 '목록을 캐싱하고 따라서 아이디어는 사용자의 사용자 목록에 고유 한을 가지고 있었고 나는 그것들이 완전히 별개라고 생각했기 때문에 만약 userA와 userB가 Bob과 친구 였다면 아무런 문제가 없었을 것입니다. 그러나 위의 오류가 있기 때문에 appearently 나는 잘못되었습니다. 그러면 어떻게 할 생각입니까? 나는 그냥 그것을 ref로 옮겨서 백업 계획 (그리고 시간을 위해)을 채울 수 있지만, 이것을하기위한 "권장되는"방법을 정말로 알고 싶습니다! ^^ –

+0

@MatthewClark 당신이 임베드 할 때 배열 필드의 다른 스키마 ('friends'와 같이)는 그 스키마에 정의 된 모든 인덱스가 또한 임베딩 (부모) 스키마의 콜렉션에서 생성됩니다. 이 문맥에서의 유일한 인덱스는'User' 문서가'friends' 배열에 같은 이름을 가진'OutsideFriend'를 포함 할 수 없다는 것을 의미합니다. 따라서 고유 인덱스가 포함 된 스키마를 포함하는 것은 거의 원하는 것만은 아닙니다. 임베디드 접근법을 여전히 사용하고자 할 때 캐시해야하는 필드 만 포함하는 고유 색인없이 'friends'에 대한 별도의 스키마를 만드는 것이 좋습니다. – JohnnyHK

+0

임베디드 접근 방식이 가장 효과적인 방법이라고 생각하지 않습니까? 이 캐시를 통해 SM 친구 중 어떤 사용자가이 시스템에 있는지 보여 주려고합니다. –

관련 문제