Не соглашусь. Текст лицензии такой, что раскрывать нужно всё. Будут ли они нападать не на DBaaS? Скорее всего, нет. Могут ли? Текст лицензии такой, что да, могут.

Не соглашусь. Текст лицензии такой, что раскрывать нужно всё. Будут ли они нападать не на DBaaS? Скорее всего, нет. Могут ли? Текст лицензии такой, что да, могут.

DBaaS обвязаны раскрывать исходный код. Но никто не запрещает вам делать после этого свой DBaaS

Право их так делать и зарабатывать деньги никто и не оспаривает

Самое смешное что для DBaaS исходный код инфраструктуры не является ключевым активом

DBaaS обвязаны раскрывать исходный код. Но никто не запрещает вам делать после этого свой DBaaS

Я не об этом. Я про то, что если я делаю что-то поверх MongoDB (не DBaaS, а просто сайт какой-нибудь), то текст лицензии не даёт мне уверенности, что мне не нужно раскрывать исходники сайта

Я не об этом. Я про то, что если я делаю что-то поверх MongoDB (не DBaaS, а просто сайт какой-нибудь), то текст лицензии не даёт мне уверенности, что мне не нужно раскрывать исходники сайта

Каким именно параграфом?

Двумя параграфами в 13-ом пункте

13. Offering the Program as a Service. If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version. “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

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

Так-то весь copyleft достаточно мутный, по этому его в ряде индустрий не используют

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

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

У абстрактных судов и юристов будет другая серьезная проблема: отсутсвие практики споров по лицензиям

И это гораздо большая проблема. Плюс в ряде юрисдикций опубликованная на сайте информация legal binding

Так что FAQ к лицензии будет конкретным юридическим аргументом

Чтоб понять что такое споры по вопросам ИС без наработанной практики, можно посмотреть на спор про защиту API между гуглом и ораклом

Я полностью с вами согласен

Добрый день. Помогите пожалуйста понять в чем дело. У меня есть база auth и коллекция users Использую mongoose. Схема такая login: { type: String, required: true, unique: true, }, password: { type: String, required: true, select: true, }, refreshToken: { type: String, }, Я создаю первый документ и всё нормально. Но когда создаю второй, уже с другим логином, монго ругается, мол MongoServerError: E11000 duplicate key error collection: auth.users index: email_1 dup key: { email: null } Я так понимаю это проблема с дублированием уникального поля email, типа email: null уже есть. Только у меня в схеме коллекции вообще нет поля email, я такое не использую. Что именно я делаю не так? 🤔

Добрый день. Помогите пожалуйста понять в чем дело. У меня есть база auth и коллекция users Использую mongoose. Схема такая login: { type: String, required: true, unique: true, }, password: { type: String, required: true, select: true, }, refreshToken: { type: String, }, Я создаю первый документ и всё нормально. Но когда создаю второй, уже с другим логином, монго ругается, мол MongoServerError: E11000 duplicate key error collection: auth.users index: email_1 dup key: { email: null } Я так понимаю это проблема с дублированием уникального поля email, типа email: null уже есть. Только у меня в схеме коллекции вообще нет поля email, я такое не использую. Что именно я делаю не так? 🤔

Удали индекс email_1 в базе. Если захочешь такое поле, проблема с duplicate null, решается через sparse: true

Удали индекс email_1 в базе. Если захочешь такое поле, проблема с duplicate null, решается через sparse: true

Спасибо!

privet vsm

Добрый день как назначить id элементу в MongoDB

Например { "title": "HOT DOG", "PRICE": 515, "id": 5},

Добрый день как назначить id элементу в MongoDB

Оно же автоматически назначается по _id

Оно же автоматически назначается по _id

А можно поменять

там случайные числа

нужно сделать по парядку

MongoDB auto increment ID - Stack Overflow https://stackoverflow.com/questions/21218651/mongodb-auto-increment-id

MongoDB auto increment ID - Stack Overflow https://stackoverflow.com/questions/21218651/mongodb-auto-increment-id

А можно _id поменять на просто id

А можно _id поменять на просто id

А зачем? Это ведь не принципиально

А зачем? Это ведь не принципиально

Для расшширения нужна

НА фронте

А можно _id поменять на просто id

По моему для монги этого сделать не получится

А можно _id поменять на просто id

_id: false

в монгусе правда, но думаю можно и без odm как-тоо

в монгусе правда, но думаю можно и без odm как-тоо

как-то можно поменять _id на просто id

ну да, выключаешь _id и вставляешь id

Всем привет. Как в монгузе создать индекс для нескольких полей. Я к примеру пишу product.index({ title: 'text', brand: 'text', category: 'text' }) В этом случае создается только индекс для title, а дальше выходит ошибка Index already exists with different options

ребята, кто нить подымал mongodb в docker контейнере, помогите с соединением вот такая ошибка выходит: UnhandledPromiseRejectionWarning: MongoServerError: Authentication failed.

😞

подскажите пожалуйста почему ругается?

почему no overload matches, ведь это корректная функция - по крайне мере по доке

здарова ребята, помогите получить ответа на пару вопросов 1 нужно ли валидировать данные на уровне базы через validator.$jsonSchema если также валидируешь в монгусе 2 как в validator.jsonSchema описать зависимости (дока по валидации не покрыла эту информацию полноценно, по крайней мере для меня)?

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

Они неудобные и их сложно дебажить

здарова ребята, помогите получить ответа на пару вопросов 1 нужно ли валидировать данные на уровне базы через validator.$jsonSchema если также валидируешь в монгусе 2 как в validator.jsonSchema описать зависимости (дока по валидации не покрыла эту информацию полноценно, по крайней мере для меня)?

В первую очередь схема на базе это попытка сделать аналог схемы в sql, позволяющей контролировать содержимое полей на уровне БД, а не кода. Это стоит использовать, если в вашем софте нет возможности обеспечить работу с кривыми данными или в БД могут писать мнодество разных скриптов, приложений, польщователей напрямую и нужно перестраховаться, чтобы данные были в нужном виде. Если приклад только один, он использует орм/одм и в нем заложены валидации или на всех этапах до базы данные валидируются, то пользы от схем на базе не будет

Всем привет, такой вопрос - у нас в системе есть soft delete на документах в коллекции (просто сетим isDeleted = true), мы храним несколько типов документов в одной коллекции, у некоторых из них есть id на другие документы, которые нужно "каскадно" точно также помечать isDeleted = true. Можно ли это как то реализовать на уровне монги? Похожий концепт на SQL ON DELETE CASCADE, но с софт делитом

Ребят, всем привет! Какой современный способ или правильный, получить последний элемент из колекции?

db.collection.find({}).sort({_id: -1}) Дальше всё зависит от языка

В Node.JS, допустим, нужно в конце дописать .toArray() и не забыть, что это асинхронная штука, поэтому в начале нужно добавить await, либо вызвать метод then (см. промисы)

В итоге получаешь массив из 1 элемента и тебе нужно получить этот элемент стандартными средствами языка

так получается это мы всё ровно проходимся по всей коллекции?

User.find({}).sort({_id: -1}) .then(user => { res.send(user[0]) })

так получилось, но я думал есть короче путь

Нет, мы не проходимся по всей коллекции

Монга сама возьмёт именно последний элемент

Монга сама возьмёт именно последний элемент

странно, у меня она просто переворачивает колекцию

User.find({}).sort({_id: -1}) .then(user => { res.send(user[0]) })

А зачем find? Можно же findOne!

А зачем find? Можно же findOne!

спасибо друг

Нет, мы не проходимся по всей коллекции

и вам спасибо

надеюсь она всё таки достаёт 1 элемент, а не все. Просто я вообще 0 в монге

В первую очередь схема на базе это попытка сделать аналог схемы в sql, позволяющей контролировать содержимое полей на уровне БД, а не кода. Это стоит использовать, если в вашем софте нет возможности обеспечить работу с кривыми данными или в БД могут писать мнодество разных скриптов, приложений, польщователей напрямую и нужно перестраховаться, чтобы данные были в нужном виде. Если приклад только один, он использует орм/одм и в нем заложены валидации или на всех этапах до базы данные валидируются, то пользы от схем на базе не будет

спасибо за подробный ответ, вы правы это все привычка максимально контролировать и типизировать данные.

User.find({}).sort({_id: -1}) .then(user => { res.send(user[0]) })

limit(1) забыли после sort

Ребят, всем привет! Какой современный способ или правильный, получить последний элемент из колекции?

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

та просто, самый последний элемент

та просто, самый последний элемент

просто так последний не получить, только первый через .find({}).limit(1). Но тут надо понимать, что первый - может быть разный в разных запросах и уж тем более если используется шардинг или чтение с реплик

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

Это можно сделать проще

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

работаете с монгой через драйвер напрямую? Если так то при использовании insertOne в ответе будет идентификатор https://docs.mongodb.com/manual/reference/method/db.collection.insertOne/#insert-a-document-without-specifying-an-_id-field

через axios делаю запрос

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

Ты можешь сам задать _id при добавление документа в коллекцию через Object ID, который есть в комплекте с любой библиотекой для работы с mongodb

хмм

Если JavaScript, то ObjectID должен лежать в пакете mongodb Чтобы сгенерировать _id, нужно выполнить new ObjectID()

точно

К тому же insertOne вроде должен возвращать созданный документ. От туда тоже можно получить _id документа

Ребят, вы в курсе, что в корпоративной версии MongoDB можно заставить всю базу храниться в ОЗУ. Значит это хорошая замена redis?

Ребят, вы в курсе, что в корпоративной версии MongoDB можно заставить всю базу храниться в ОЗУ. Значит это хорошая замена redis?

Смысл

Для своих задач редис лучше

Ребят, вы в курсе, что в корпоративной версии MongoDB можно заставить всю базу храниться в ОЗУ. Значит это хорошая замена redis?

так никто не хранит в ОЗУ кэш щас, все хранят в аптейне