Приложение Mongoose CRUD: возможно ли сохранить избранное как статический документ, а также ссылку?

Question

Я создаю приложение CRUD, которое использует экспресс, mongodb и mongoose. У меня есть 2 схемы (для простоты я буду называть их пользователями и контентом). Общая функциональность приложения заключается в том, что пользователи создают контент, который могут просматривать все остальные пользователи. Содержимое может быть отредактировано и удалено создателем, а также добавлено в избранное другими пользователями. Я хочу, чтобы пользователи могли просматривать избранное в 2 разных версиях: 1 для версии в то время, когда она была добавлена ​​(статический контент), и 1 для текущей «живой» версии (поскольку контент мог быть отредактирован послеfavourited).

Я понимаю, как создать статический фаворит (я могу скопировать контент в массив избранного пользователя) и живой фаворит (я могу сохранить ссылку на контент в массиве избранного пользователя). Что я не могу понять, так это как использовать оба этих метода одновременно, чтобы пользователь мог щелкнуть по одному из своих избранных и переключаться между статическим и живым контентом. Моя идея состоит в том, что, поскольку скопированный контент в избранных пользователя содержит поле ObjectId контента, я должен иметь возможность заполнить его и получить доступ к живому контенту из статического контента. Я сумасшедший?

User {
  (some properties of the user...)

  favorites: [{_id, title, body,...},{_id, title, body,...}...]
}

Content {
  objectId,
  title,
  body,
  (more properties of the content...)
}

Сейчас моя структура похожа на вышеприведенную, поэтому я могу циклически просматривать избранное пользователя и отображать статический контент (потому что фактический контент был скопирован в избранное, а не просто как ссылкак содержанию). Что мне интересно, так это то, что я могу заполнить ObjectId в избранном, чтобы получить доступ к живой версии этого контента, чтобы я мог рендерить живую версию в дополнение к статической версии. Есть ли лучшая практика для достижения этой функциональности?

Answer 1

Я считаю, что эта структура может выполнить то, что вам нужно

User{

 _id: ObjectId("USER ID")

 favorites:[ ObjectId("CONTENT 1"), ObjectId("Content 2")]

} 

Content{

  _id:ObjectId("CONTENT 1")

  CreatorID: ObjectId("USER ID")

 OrignalContent:{
        title: title 1 
        body: body 1
 }
 UpdatedContent:{

    title: UpdatedTitle1
    body: UpdatedBody1
 }

}

Позвольте мне объяснить, что происходит, поэтому User будет иметь массивы _id и favorites, в которых будут храниться _idиз Content. Тогда Content будет иметь CreatorID, чтобы мы могли отслеживать, кто создал контент, и редактировать его. Так что, если user хочет увидеть Content1, вы можете найти его с помощью _id и получить, как 1014 *, так и UpdatedContent зависит от того, кого он хочет видеть.

Таким образом, у вас не будетчтобы взять snapshots и скопировать fields в каждый отдельный объект в массиве, вы просто сохраняете ссылку на него, и Updating и deleting будут довольно простыми.

Убедитесь, что owner изContent отправляет запрос на обновление, вы обновляете только UpdatedContent, а не orignalContent.

Обновление 2

В соответствии с вашим комментарием вы хотите включить некоторыевид versioning. Я мог бы высказать вам свое мнение, но, возможно, есть лучший способ сделать это.

User{

 _id: ObjectId("USER ID")

 favorites:[ {ID:ObjectId("CONTENT 1"),version: v1}, {ID:ObjectId("Content 2"),version:v2}]

} 

Content{

  _id:ObjectId("CONTENT 1")

  CreatorID: ObjectId("USER ID")

 OrignalContent:{
        title: title 1 
        body: body 1
 }
 UpdatedContent:{

 v1:{
    title: UpdatedTitle1
    body: UpdatedBody1
   }

   v2:{
    title: UpdatedTitle2
    body: UpdatedBody2

 }

}

Этот подход будет хранить Duplicate все properties снова и снова (если у вас 100 версий, то100 подобных свойств). Альтернативой может быть сохранение changed properties only (Metadata) (таким образом, не каждое свойство повторяется, только измененное).

1-й способ позволит вам писать простые запросы к find и update, но будет потреблять память.

2-й способ может сэкономить вам немного памяти, но maintaining и writing queries будут немного утомительными