вот последнее — очень опасная логическая ошибка

я не говорил про отсуттсвие авторизации

она есть, естественно

если ssl нет, то от неё толку мало :)

ну вообще монговцы заявляют, что она секурна

SCRAM-SHA-1 да, а вот CR нет

Ну про CR речи не идёт

Подскажите, как правильно фильтровать данные. Есть вот такая коллекция: {a: 1, b: 'x'} {a: 1, b: 'y'} {a: 3, b: 'z'} Хочу фильтровать ее, используя такой массив: [{a: 1, b:'y'}, {a: 3, b:'z'}] Т.е. в результате должно остаться только: {a: 1, b: 'x'}

никак не пойму, как мне это правильно сделать

Если я тебя правильно понял, ты хочешь исключить из результатов несколько документов по совпадению двух ключей a и b?

совпадение двух ключей из объекта, который в массиве, т.е. таких пар ключей может быть больше 1

я пробовал строить массивы из фильтра, массив значений a и b, а потом использовать $nin, но получилось как-то не так

Иди перечитывай про запросы

$nin тебе не нужен

Тебе нужно внимательно читать

Из твоей не очень внятной постановки задачи можно сделать только один вывод — ты решаешь свою задачу совершенно неправильно

Начать нужно с простого: логических операций $or и $and

И разобраться наконец с тем, как вообще работает язык запросов в монге.

Потому что $nin не для этого совершенно, у него семантика иная

понятно

Попробуй пробежать глазами по query lang и переосмыслить свою задачу

начинать рекомендую вот от сюда: https://docs.mongodb.com/manual/tutorial/query-documents/

и вот отсюда: https://docs.mongodb.com/manual/reference/operator/query/

ну и за одно убедится что концепция документов до конца понятна. это тут https://docs.mongodb.com/manual/core/document/

Спойлер: тебе надо (a == a1 && b == b1) || (a == a2 && b == b2). массивы не покатят

Люди, нужен спец по монге на проект по апгрейду с версии 2.2.7 на 3.х, на хаускипинг и на разовые мелкие задачи. Система в Питере. Два шарда. Всего данных условно два раза по 100гб. Кто готов поговорить? Или может быть посоветует кого?

Я готов поговорить

на следующей неделе туда патчи поедут

чот нету ;)

чот нету ;)

неделька выдалась сильно сложнее чем бы я хотел. на этой должен добраться

Привет, подскажите по монге, допустим есть простая схема: { property: { type: [String] } } Есть поле - массив, дак вот, можно ли как-то при валидации этого поля кинуть ошибку для какого-то конкретно значения? Просто если делать к примеру так: Schema.path('property').validate(function () { ... }, 'Property error'); То в ошибке у нас будет весь массив

{ "58f5b2530a975a13fb0c21ff" : { "persName" : "Огонек" }, "58f5b2530a975a13fb0c2200" : { "persName" : "Дриада" }, ..... } как мне перебрать эти поля (58f5b2530a975a13fb0c21ff ..) в forEach ?

3.4.4 на подходе: https://docs.mongodb.com/manual/release-notes/3.4-changelog/#id1

Привет, подскажите по монге, допустим есть простая схема: { property: { type: [String] } } Есть поле - массив, дак вот, можно ли как-то при валидации этого поля кинуть ошибку для какого-то конкретно значения? Просто если делать к примеру так: Schema.path('property').validate(function () { ... }, 'Property error'); То в ошибке у нас будет весь массив

Думаю что никак, потому что валидаторы работают целиком на значении ключа. Но валиадация новая поделка, могу не знать.

{ "58f5b2530a975a13fb0c21ff" : { "persName" : "Огонек" }, "58f5b2530a975a13fb0c2200" : { "persName" : "Дриада" }, ..... } как мне перебрать эти поля (58f5b2530a975a13fb0c21ff ..) в forEach ?

эти «поля» называются ключом. Суяд по forEach разговор или о mongoshell или о ноде. В самой монге нет forEach.

чот нету ;)

сегодня будет докеровский контейнер, 1 экспортер на одну ноду и замена конфига на параметры и envvar

йуху!

если мне опенстек ещё рогов не накрутит

не могу нормально собрать тестовый стол, блин :(

@dd_bb дать админа @freeseacher ?

¯\_(ツ)_/¯

как хочешь!

ну ты тут один последнее время. дам тогда. раз существующий порядок непротив, а человек просит:)

@freeseacher done

tnx

tnx

зачем оно тебе?

http://lesswrong.ru/w/%D0%9F%D0%B0%D1%86%D0%B8%D1%84%D0%B8%D0%B7%D0%BC_%D0%B3%D1%83%D0%B1%D0%B8%D1%82_%D1%83%D1%85%D0%BE%D0%B6%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D1%81%D0%B0%D0%B4%D1%8B

так что что бы не понижать уровень дискуссии

так у нас тут нормальные дискуссии

Думаю что никак, потому что валидаторы работают целиком на значении ключа. Но валиадация новая поделка, могу не знать.

Да, походу так и есть. Можно конечно ещё заморочиться типо в хуке сделать invalidate и туда прокинуть значение, но это чет слишком запарно мне кажется

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

Если по чесноку, я считаю что нельзя эти валидаторы использовать вообще.

Потому что у тебя бизнес-логика в субд утекает

Возможно) я только постигаю бэкэнд, в будущем постараюсь такого не делать

Потому что у тебя бизнес-логика в субд утекает

В 2017 так никто не делает, ага, а вообще это нормальная практика раньше была. Сейчас все с dal работают. Собственно по рассказам тех кто ещё так работал — ничего плохого в этом нет

А для каких таких кейсов вы используете монго? Я использую для игрового сервера, пошаговой сессионной мобильной игры. В целом удобно что json.

MEAN стек

В 2017 так никто не делает, ага, а вообще это нормальная практика раньше была. Сейчас все с dal работают. Собственно по рассказам тех кто ещё так работал — ничего плохого в этом нет

Это никогда не было нормальной практикой. :)

всем привет Подскажите, если я при баллансировке получаю вот такое: Migration Results for the last 24 hours: 394 : Success 838 : Failed with error 'aborted' что бы это могло значить? Почему failed? Куда покопать?

Это никогда не было нормальной практикой. :)

Ну почитай про BLL в таком случае

Ну почитай про BLL в таком случае

ты мне ещё про OLE предложи почитать, ага

вместо того чтоб за аббревиатурами прятаться, ты мне расскажи когда хранение логики в СУБД оправдано.

и почему в этом случае положительные эффекты перевесят все минусы такого подхода

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

И то ¯\_(ツ)_/¯

Смотря какой проект

официальный докерфайл для монги это феерия сладострастия просто

Почему?

https://github.com/docker-library/mongo/blob/master/3.4/docker-entrypoint.sh

врятли в 200 строчек можно сделать что то хорошее

я пропустил момент когда они туда бустрапинг юзеров добвали

потому что это подстава прямо пиздец. в месте с keyFile включается аутентификация. а я не мог понять почему у меня кластер никак между собой авторизироваться начать не может

плюс подстава: rs.initialize почему-то без аутентификации работает

убил бы

а как я понимаю defaults в схеме можно только синхронно выставить? Просто мне нужно выставлять дефолтное значение полю при создании субдокумента и я вот думаю, сделать ли defaults синхронной функцией, перед ней вызывать асинхронную, кешировать значение, и следующим действием создавать документ(выглядит как немного хуевый дизайн потому что код расбросан будет) или делать это всё в 2 квери не юзая defaults вообще, будет читабельнее, но это 2 запроса к бд, а не 1

что на самом деле в моём случае в принципе приемлемо, нет нагрузки и не предвидится