но зачем?

Так в чем проблема?

тем, что докер не lxc

я лучше контейнер буду создавать и мочить, так проще

нафига там что-то дропать?

да

драйвер или --eval, выбор верный был.

не монтируй тогда ничего из контейнера и будет тебе один контейнер == одна база

логично

я обернул вызов теста монго контейнером в мейкфайле, если он фейлится, то контейнер не убивается... щас починим

дропать базы, особенно в скриптах — к проверке бекапов

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

потому что причины

вот это меня как раз напрягало

тем, что докер не lxc

Это обёртка. И тем не менее это не отвечает на вопрос, почему нельзя залезать в контейнеры.

потому что докер вам дали для абстракции

если ты лезешь в контейнер, то ты или разрабатываешь/отлаживаешь контейнер или ты не так варишь докер

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

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

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

На проде никто в контейнеры залезать не будет

Чтобы чё то сделать

А на тестах я не вижу проблем

ох

подход все же неверный. Ну это к холивару уже идет все.

У докера появился gc.

Есть у кого видосики с старых курсов Mongo University? Или где можно посмотреть хорошие курсы по Mongo

ох

Дело говоришь, поддерживаю.

Привет всем, есть вопрос про субд, маленькая дилемма. Допустим юзер может создавать так называемые компании, просто объект в бд и у этих компаний могут быть созвездия(массив с набором объектов) Я думал как можно это красивее всего организовать и пришел к выводу сделать что-то типо отдельная запись для каждой компании(но не несколько записей на одну компанию) и внутри нее массив "множество созвездий" и уже внутри этого массива n-нное количество массивов с объектами

но сейчас я не особо уверен в правильности такой записи

"companyName" : "КряКря" "constellations" : [ [{}], [{}] ]

так наверное понятнее всего будет

В чем вопрос-то?

правильно ли так будет

или же надо делать несколько записей на одну компанию

и в каждой отдельно созвездие

или же делать что-то типо companyName: "Кря кря", "constellations1": [{}], "constellations2": [{}]

Всё зависит от многих факторов, но в общем случае 1 запись на созвездие больше подходит для реляционных СУБД

так значит первая запись с массивами в массиве будет в данном случае будет наиболее правильной?

я просто только как месяц начал заниматься backendом и еще не всегда уверен в правильной субд

Ну с выбором СУБД стоит быть посерьезней, чтобы потом не пришлось в срочном порядке всё переписывать

ну это проект как раз таки для трениворок, чтобы в будущем не было ситуаций о которых ты говоришь

если знаешь что грамотное можно почитать, то буду благодарен

Привет всем, есть вопрос про субд, маленькая дилемма. Допустим юзер может создавать так называемые компании, просто объект в бд и у этих компаний могут быть созвездия(массив с набором объектов) Я думал как можно это красивее всего организовать и пришел к выводу сделать что-то типо отдельная запись для каждой компании(но не несколько записей на одну компанию) и внутри нее массив "множество созвездий" и уже внутри этого массива n-нное количество массивов с объектами

Если у тебя эти созвездия всегда разные то более менее правильно, если они могут быть использованы в нескольких компаниях создай отдельную коллекцию созвездий и компаний, а в компании выписывай их айдишники

{messages: {message_id: id, message_text: text},{message_id: id, message_text: text} ... } How to SORT objects in MESSAGES by message_id? Python

{messages: {message_id: id, message_text: text},{message_id: id, message_text: text} ... } How to SORT objects in MESSAGES by message_id? Python

See https://docs.mongodb.com/manual/aggregation/

See https://docs.mongodb.com/manual/aggregation/

IMO, it's extremely slow and unusual to sort subdocuments via aggregation pipeline

a simple sorted() function in python will do its job well

он умеет в русский.

уже спрашивал тут какой-то энтрилевел вопрос.

сабдокументы да, сортирни в питоне.

тимсорт стабильный алгоритм

достаточно быстрый.

воу воу, чятик оживает. Может быть, не зря я тут уже год, хоть в монге ни в зуб ногой (да - да) Мне прислали тестовое а ля "попробуйте разобраться в MERN" форкните гитхаб и пилите комменты к статье. Кто нить поможет мне освоить? Я пока дальше jquery не ходил, а у меня при установке сплошные эрроры (Fedora25)

ох уж эти нью фаги

Привет. Есть коллекция, в которой хранятся документы в формате { firstName: "Имя", lastName: "Фамилия" } Как можно сделать выборку по двум полям, чтобы можно было на сайте сделать поиск по строке "Имя Фамилия" и совпадение не обязательно должно быть точным

лучше отдельно поиск сделать используя какой нибудь сфинкс?

да тут без разницы особой, интересно больше как сделать поиск по нескольким полям

в голове пока только идея парсить поисковую строку и дальше искать по каждому ключу через $or

наверное лучше вне монги такое делать..

Мне кажется вам нужны более специализированные решения типа ElasticSearch

Там и парсить ничего особо не придется. Главное правильно выбрать токенизаторы, токен фильтры

ну да, я об этом и подумал изначально

спасибо

господа а что то случилось с репой монги под деб/убунту ?

говорит пакеты невозможно аутентицировать

деб какой версии?

деб8 монго 3,2

Можно ли как-то человечески группировать данные в аггрегации по дням, неделям, месяцам?

Кстати, MongoDB Applied Design Patterns годная книга?

@dd_bb привет, расскажи какую проблему на практике решает dbref? я пока не понял применения, если я везде могу таскать objectId (_id) зависимого документа

Разве dbref - это не просто синтаксический сахар вокруг _id в драйвере?

ох уж эти нью фаги

а ведь это достижение, остаться ньюфаней 1,5 года

ребят привет. подскажите, есть ли какие то бэстпрактисес по архивированию старых данных в монге? не дамп\рестор

Разве dbref - это не просто синтаксический сахар вокруг _id в драйвере?

Это так, я вот тоже не совсем понимаю как это облегчит жизнь и что-то упростит

Возможно, для ODM для связей между коллекциями

Id без коллекции не является полной ссылкой. DbRef решает эту проблему.

Т.е. это перенос информации об источнике данных из уровня приложения, в уровень субд.

По готовому стандарту

Плюс это даёт гибкость: можно хранить масссивы ссылок на разные коллекции например.

Привет! Не подскажите ли какие способы заставить монгу работать быстрее? Есть коллекция, в которую кладутся простые документы. Индекс по _id. Если документ уже есть, то он заменяется, если нет, то создается. Всё просто. На деле столкнулся с проблемой, что работа скрипта замедляется в геометрической прогрессии. Первый миллион документов обрабатывался за минуту-другую. Сейчас 10млн документов и каждый следующий миллион вставляется или обновляется почти за час. Скрипт на ноде. модуль - mongodb. При анализе очередного миллиона документов, скрипт сначала вытаскивает уже записанные элементы, апдейтит их на своей стороне и кладет обратно в базу. используются два метода collection.findOne - что бы найти collection.save - что бы добавить или заменить. Может я что то упустил и делаю что то не так?

FindOne по каким полям?