Дело в том, что бизнес-требования почти всегда сводятся к описанию конечной, готовой концепции продукта. В реальном мире коллекции данных, обладающие нумерацией натуральных чисел (1, 2, 3...) встречается повсеместно. Логично предположить, что в таком случае часто возникает и необходимость в авто инкременте.

Видел я апи с инкриментальным урлом. Отличное решение. Можно спарсить все заказы и узнать адреса всех клиентов, количество даставщиков в штате, сколько заказов в день выполняют, как часто клиент делает заказ, фио доставщиков, какая текучка кадров и прочее. И всё с одного лишь урла --- оставьте отзыв о нашей работе. Продолжайте делать автоинкримент и выставлять его наружу.

OWASP как раз описывает данную уязвимость как довольно частую проблему https://wiki.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

Видел я апи с инкриментальным урлом. Отличное решение. Можно спарсить все заказы и узнать адреса всех клиентов, количество даставщиков в штате, сколько заказов в день выполняют, как часто клиент делает заказ, фио доставщиков, какая текучка кадров и прочее. И всё с одного лишь урла --- оставьте отзыв о нашей работе. Продолжайте делать автоинкримент и выставлять его наружу.

Ну к примеру, в текущей проекте у меня возникла такая необходимость. В системе существуют некие объекты, обладающие порядковой нумерацией. Причем это даже не прихоть бизнеса, это само по себе логично, природа объектов это подразумевает сама по себе. Для решения проблемы авто инкремента мне пришлось сделать _id кастомным, который состоит из префикса и как раз таки порядкового номера. Соответственно, при вставке нового документа, при конкурирующем write, если 2 человека будут добавлять 2 дока с одинаковым порядковым номером в айдишнике, неизбежно возникнет конфликт записи с одним документом, а другой добавится успешно. Я перехватываю ошибку, и запускаю функцию заново. Поймите, тут речь не о том, что это жизненная необходимость, без которой программисты не могут монгу использовать. Это просто та фича, которая бы сделала жизнь проще.

Дело в том, что бизнес-требования почти всегда сводятся к описанию конечной, готовой концепции продукта. В реальном мире коллекции данных, обладающие нумерацией натуральных чисел (1, 2, 3...) встречается повсеместно. Логично предположить, что в таком случае часто возникает и необходимость в авто инкременте.

Добрый вечер. Проблема с mongoexport. На мой запрос mongoexport -h 10.0.0.3:27017 -d mybase -authenticationDatabase=admin -u ”my_user” -c users --type=csv -o users.csv Получаю Failed: (Unauthorized) not authorized on mybase to execute command { listCollections: 1, filter: { name: "users" }, lsid: { id: UUID("") }, $db: "mybase”, $readPreference: { mode: "primaryPreferred" } }

Разве там нужно равно? Вроде оно должно ставиться, только если писать - -username=

Всем привет можете мне помочь как можно реализовать У меня есть юзер хочу сделать так - есть документ хочу отправить другому юзеру я отправляю SENT и у меня статус документа становиться SENT - а когда другой юзер заходит свой кабинет у него должен стоят статус RECEIVED, если он принимает документ ACCEPTED и уменя и унего статусы должны поменятся статусы ACCEPTED как сделать такой запрос ? Mongodb база и schema

2. Когла другой юзер зашел в свой профиль обновляешь всем документам что ему прислали статус на ресивд КАК ОБНОВИТЬ ?

2. Когла другой юзер зашел в свой профиль обновляешь всем документам что ему прислали статус на ресивд КАК ОБНОВИТЬ ?

можете помочь >?

1. Создаете 2 файла, например user.model.js и document.model.js 2. Описываете через new mongoose.Schema какие поля у вас есть у юзера и документа, в частности, у документа должно быть поле status у которого enum с описанными вами статусами, конвертируете схему в mongoose.model и экспортируете из файла. 3. Создаете сервисы, которые будут проверять и выставлять статусы 4. Когда пользователь отправляет документ, вы в сервисе пишете примерно такую логику: const recipient = await userModel.findOne({login: recipientLogin}) const newDocument = await documentModel.create({status: 'SENT', from: userId, to: recipient._id}) 5. Когда получатель заходит на страницу с документами, то фронт отправляет запрос на обновление статуса. В этом сервисе вы пишите const recievedDocument = documentModel.updateOne({_id: documentId}, {$set: {status: 'RECIEVED'}}, {new: true}) 6. Когда пользователь принимает документ, вы пишете в третьем сервисе примерно такое const acceptedDocument = documentModel.updateOne({_id: documentId}, {$set: {status: 'ACCEPT'}}, {new: true})

Вопрос а если другой пользователь заходит и идёт запрос и меняется статус на RECEIVED и он не принимает документ просто выходит из кабинета и у меня тоже статус поменяется же вид так ?

Вопрос а если другой пользователь заходит и идёт запрос и меняется статус на RECEIVED и он не принимает документ просто выходит из кабинета и у меня тоже статус поменяется же вид так ?

На каждую отправку документа вы создаетн запись в базе данных Я и так хочу сказать на каждый док сделать два копии по их ID и менять статусы но тогда в базе дубликатов будет много статусы разные но док одинаковый

У нас профессиональное сообщество, пожалуйста, относитесь ко всем участникам с уважением. Сообщество необходимо для помощи другим участникам. Здесь не принято посылать в гугл, предлагать почитать документацию или поискать на SO.

может кто найдётся который хорошо разбирается

Уважаемый админ, есть вопрос, так как я тут новенький. Как видно из вопросов участника чата, для того, чтобы точно ответить на поставленный им первоначальный вопрос, необходимо дополнительно рассказать про базы данных, их архитектуру, проектирование, рассказать про MongoDB, про mongoose и, возможно, про разработку backend логики. Данные тексты будут продолжительными по времени, и явно выходят за рамки этого чата. Как в таких случаях принято поступать? И не является ли неуважением к другим участникам чата задавать вопросы без базовых знаний?

Уважаемый ( GooDNeTH ) спасибо зато что ответили на вопрос но ваш ответ не оптимальный вариант для решение задачи, тут чат для профессиональное сообщество ( необходимо для помощи другим участникам ) А жаловаться это неправильно и не профессионально.

Реализация такого механизма не должна быть в базе данных Есть 1 документ. User1 его отправил, User2 получил. У этого 1 документа статус общий для них обоих в базе Когда User1 получает данные о документе, сервис, который отдает данные смотрит, что user 1 - это отправитель, и у докумнта общий статус и в ответе заменяет статус на SENT Когда user 2 смотрит на данные документа, сервис смотрит что это получатель и статус общий и заменяет общий статус на ресивд Когда user 2 принтмает документ, общий статус меняется на акссепт и когба оба юзера смотрят на документ то сервис ничего не заменяет а отдает как есть Для user 3 и других можно заложить любую логикк которая вам нужна

скорее все проигнорят, так как ощущение, что вы сами ничего не сделали, прежде чем прийти с вопросом + выглядит не как «нужна помощь», а «сделайте за меня»

Благодарю за вашу помощь

Смотрю хотя другие помогают, А ты сам что-то умеешь ? Он не просил сделать за меня просил помощь грамотные программисты знают а который как ты из себя делает инштейна будет так остоватся ☕️

ребят, помогите есть сервер A (node.js), есть сервер B (mongodb) сервер A подключается к серверу B все работает прекрасно но в один момент при подключении получаем следующее: failed to connect to server [IP:PORT] on first connect [MongoNetworkError: connect EADDRNOTAVAIL IP:PORT - Local (IP:PORT)] ошибка - EADDRNOTAVAIL ufw настроен, порядок, проверяли много раз работает работает, херак, перестает могут ли быть лимиты в самой монге? куда смотреть?

Ребята, подскажите, пожалуйста, как реализовать сортировку в монго по типу ORDER BY (case: status =Packing: 1 else 0) DESC, deliveryDate DESC

в агрегации перед сортировкой добавить стейдж $addField для добавления поля в котором будет высчитываемое поле по статусу. Потом уже по этому полю и деливериДейт сортировать

Парни! Привет. Я на сайте монги создал тестовую базу. Как мне от неё реквизиты получить я что-то запутался. Желательно конекшн стринг

В облаке которая?

ага

Почему, если пользователь отправит 2-3 обновления моментально, то в БД он попадет несколько раз? Должен попасть только один раз. Тут что-то типо race condition и я не знаю как это решить. Использую Node.js mongoose

let Users = collections; updates.on('message', async(ctx, next) => { let _user = await getUser(); if(!_user) { let $user = new Users(); await $user.save(); } }); ?

no...

новая переменная...

ты спросил как это решить...

печально...