Zloy-Dobry
Норм структура
SvPupok
Начните с ограничения сетевого доступа
Hopf
Дело в том что я должен выплачивать деньги по балансу, если вместо 100 руб кто-то напишет 1 млн, то придется платить 1млн
тогда проще всего сделать так, чтобы каждые изменения проверялись вручную :)
Ilyas
Вообще пока я проект не делал, ну заранее разбираюсь с этим, так как я Frontend разработчик.
Просто я хочу сказать, даже если ограничить сети сделать всевозможное, есть 100% гарантия что хакер не сможет изменить значения?
Ilyas
Мне кажется что сможет. И поэтому нельзя хранить баланс в цифрах, а нужно придумать какую-ту другую модель хранения
Zloy-Dobry
Вообще пока я проект не делал, ну заранее разбираюсь с этим, так как я Frontend разработчик.
Просто я хочу сказать, даже если ограничить сети сделать всевозможное, есть 100% гарантия что хакер не сможет изменить значения?
А, тут становится сразу все ясно.
Ответ на второй вопрос выше.
Zloy-Dobry
Нет, ни у кого, 100% гарантии
Ilyas
А, тут становится сразу все ясно.
Ответ на второй вопрос выше.
Окей. Мне нужно хорошо подумать. Мне кажется что что-то помимо хранения чисто цифр, можно придумать
SvPupok
Что вам мешает хешировать данные?
Ilyas
Что вам мешает хешировать данные?
Я об этом тоже думал. Пока что разбируюсь в этой теме. Но если хешировать баланс как его расхешить?
Zloy-Dobry
Окей. Мне нужно хорошо подумать. Мне кажется что что-то помимо хранения чисто цифр, можно придумать
Если вы фронтендер, делайте свою работу. А вопросы хранениния лучше доверить специалистам
CC-BY-SA-4.0/Docker-ce30.0
Мне кажется вы перегибаете.
Ilyas
Если вы фронтендер, делайте свою работу. А вопросы хранениния лучше доверить специалистам
Ну мне все таки интересно изучать новое
Zloy-Dobry
Так изучайте
yopp
Обсуждение вышло за рамки этой группы
Ilyas
Окей
Ilyas
Спасибо
Zloy-Dobry
Тут вам всей темы никто не объяснит
yopp
Вероятно через $arraytoobject и push
yopp
Но это плохая идея
yopp
Лучше делать поддокументы с фиксированной структурой: {t:,v:}
Zloy-Dobry
Ты о чем сейчас?
Zloy-Dobry
Точнее к чему?
yopp
К тому, что динамическое именование ключей имеет ряд фундаментальных проблем и на мой взгляд является плохой практикой. Не важно где: в самих документах или в их агрегациях. Даты в виде ключей (а это per se не возможно, только через каст в строку) создадут больше проблем чем решат
Zloy-Dobry
Прост не понятно, на что
Zloy-Dobry
Тишина такая и тут хобо
yopp
Тема не для этого чата
Nick
э, человек спросил, надо начтавить ан путь истинный
yopp
В личку можно продолжать наставлять
Anonymous
Здравствуйте, подскажите, пожалуйста... Есть коллекция Settings -> объект с полями event: "isGameOntime" и timer: {value: false, min: 1, sec: 0, millsec: 0}
как я могу через JS изменить поле timer.value?
Anonymous
Settings.update( { event: 'isGameOnTime' }, { $set: { "timer.$.value" : false } } );
Anonymous
так не получается
Nick
без доллара
Nick
timer.value
Nick
доллар нужен при работе с массивами
Anonymous
Действительно)) Все работает, спасибо
Anonymous
Да, я так и понял уже.. просто есть еще похожий функционал с массивами, вот и скопировал с долларом... спасибо
Anonymous
когда вызываешь createIndex, то он будет каждый раз делать индекс или только первый раз делать, а затем при insert обновлять? createIndex вызывать после insert или перед find?
yopp
createIndex создаёт индекс. Дальше индекс пополняется и обновляется автоматчески (по insert / update / delete), ничего дополнительно делать не надо.
Николаич
Кто mongo-migrate юзает?
Есть API сервер на express + mongo. Крутится в Docker контейнере.
Как бы автоматизировать выполнение миграций? Чтоб во время билда контейнера накатывались.
А то щас приходится после деплоя заходить ручками в контейнер и выполнять команду.
Zloy-Dobry
Бось спрасить, но зачем?)
Rocket
Переписав код, данные сами магическим образом обретут новую структуру?
Николаич
Ну вот и я не знаю чему люди удивляются.
Николаич
Ну монге не обязательно, чтобы у всех документов в коллекции была одинаковая структура.
Просто мне так привычнее и меньше путаницы.
Да и ошибок не возникает из-за отсутствующих полей.
Anonymous
спс
Алексей
Парни, такой вопрос, на сколько большой документ вы делаете, я имею ввиду, когда вы понимаете, что нужно выносить ссылку на этот подобъект(поддокумент), а не помещать его целиков внутри нашего документа. Просто после sql немного ломает мозги, спасибо
Алексей
Если по конкретнее, допустим есть модель user, у него может быть массив friends, который может быть любой длины, лучше его вынести в отдельную можель или оставить вложенной
Hopf
Парни, такой вопрос, на сколько большой документ вы делаете, я имею ввиду, когда вы понимаете, что нужно выносить ссылку на этот подобъект(поддокумент), а не помещать его целиков внутри нашего документа. Просто после sql немного ломает мозги, спасибо
Насколько я знаю максимальный размер документа - 16мб.
Или вопрос в другом?
Алексей
Вопрос в целесообразности использовании вложенности объектов друг друга, либо выносить в отдельную сущность.
Anonymous
в случае user, friends не вижу смысла выносить - это только усложнит. Есть смысл выносить если объект большой и при этом он используется многими другими объектами, а у каждого user свой firends, два юзера не могут иметь один и тот же массив firends (могут но вряд ли)
Aleksandr
Ну так разве в этой задаче friends не состоят из таких же юзеров?
Anonymous
ну да, но сам массив ссылок не надо выносить
Алексей
нет, там ссылки на других user
Алексей
алекс, то есть большой массив friends не будет ударять по производительности, и по скорости запросов к user?
Aleksandr
Так а что правильно хранить в таком массиве?
Aleksandr
Уже готовые объекты френдов, или просто их список id ?
Aleksandr
Ведь у разных юзеров может быть в друзьях один и тот же друг
Aleksandr
И будет дублирование информации
yopp
Надо исходить из того зачем вам друзья. Друзья это вообще граф обычно. Для них так вообще отдельные хранилища есть (но по отзывам они в среднем так себе, но тут скорее к математике вопрос)
yopp
В массивах надо хранить те вещи, которые разумно ограничиваются. Если вещи не ограничиваются, то их лучше денормализировать.
Можно заводить например коллекцию связей, где в одном документе не более 1000 друзей. См https://docs.mongodb.com/ecosystem/use-cases/storing-comments/#hybrid-schema-design
Но без конкретного кейса очень тяжело советовать.
Alexander
а в чем существенное отличие между enterprise и community версиями?
Alexander
в частности интересует вопрос бесплатного использования
Alexander
или обе версии можно использовать в коммерческой эксплуатации без каких либо проблем?
Zloy-Dobry
http://www.gnu.org/licenses/agpl-3.0.html
Zloy-Dobry
Вроде так
Алексей
В массивах надо хранить те вещи, которые разумно ограничиваются. Если вещи не ограничиваются, то их лучше денормализировать.
Можно заводить например коллекцию связей, где в одном документе не более 1000 друзей. См https://docs.mongodb.com/ecosystem/use-cases/storing-comments/#hybrid-schema-design
Но без конкретного кейса очень тяжело советовать.
могу конкретизировать, хранить нужно ссылку id, на другого friend, потому что это просто другой user, который связан связью, странная тавтология)
Алексей
я привел часть конкретики, что бы вопрос не заивать, на самом деле у этого user, может быть множесто друзей, подписчиков, тех на кого сам подписан, групп и так далее
Алексей
то есть колличество таких массивов за ранее не известно, соответсвенно не известно и размер
Anonymous
ну ясен пень что тут надо всё в один документ кидать - а кидать в несколько документов - это усложнять только жизнь себе
Anonymous
один юзер - один документ
Max
В репозиториях свежая версия 3.4. появилась, 3.4.14
На сайте монго значится как upcoming
скоро аннонс должен быть
Алексей
Спасибо alex, и все другим кто помог)
Petro
Как можно посмотреть oplog, на mongodb atlas?
yopp
или обе версии можно использовать в коммерческой эксплуатации без каких либо проблем?
Ты без покупки лицензии не имеешь права использовать Enterprise в любых целях, кроме ознакомительных.
Community Edition, можешь использовать в коммерческих целях.
Alexander
понял, спасибо
yopp
Емнип, лицензия начинается от 5к за data bearing сервер в год.