У меня есть проект, в котором мы использовали простые неверсированные значения для документов:
{
_id: <someid>,
prop1: 'foo',
prop2: 'bar',
prop3: 'baz'
}
Я хотел бы обновить метод, который сохраняет значения опор, чтобы начать сохранять значения как версии в массиве, чтобы выглядит так:
{
_id: <someid>,
prop1: [{ value: 'foo', createdAt: <someDate>}],
prop2: [{ value: 'bar', createdAt: <someDate>}, { value: 'barrrrr', createdAt: <someDate>}],
prop3: 'baz'
}
Я бы хотел, чтобы в моем запросе на обновление $push новый объект значения опоры , если уже был массивом, или $set, чтобы `[{значение: 'новое значение', createdAt: + new Date ()}], если нет. В идеале это позволило бы мне беспрепятственно переводить данные для управления версиями с течением времени. На стороне поиска, если это не массив, мы просто рассматриваем единственное значение, которое существует, как эталонную версию, и всякий раз, когда что-либо обновляется, эта опора преобразуется в новый формат.
Я пытался найти пример того же варианта использования: может ли кто-нибудь указать мне в правильном направлении?
ОБНОВЛЕНИЕ:
После того, как я был указан в правильном направлении, я смог использовать конвейер агрегации в комбинации с обновлением делать то, что я хотел. Часть ключа заключалась в том, чтобы отказаться от попытки переключения между установкой и вытягиванием - вместо этого я мог использовать вспомогательный метод $concatArrays для выполнения sh добавления массива другим способом. Вот базовый c шелл-код, с которым я работал, просто чтобы показать структуру:
db.test.docs.update({ key: 2 }, [
{
$set: {
prop2: {
$cond: {
if: { $isArray: '$prop2' },
then: {
$concatArrays: [
'$prop2',
[
{
value: 'CONCAT!'
}
]
]
},
else: [
{
value: 'SET!'
}
]
}
}
}
}
]);