Блин, надо было сразу вам написать

2d index !== 2dsphere?

Не надо тут этого.

прошу прощения, просто больно дорогой софт

надо написать, мб 3м странам сделают скидку

прошу прощения, просто больно дорогой софт

Если это для работы, то это совсем не дорого

Для учебы у них есть годовая лицензия бесплатная https://studio3t.com/discount/education

Но вообще, не можете позволить — пользуйтесь бесплатным.

ок, принято

привет всем. кто-нить в go шарит?

А какой вопрос?

блн я уже и забыл

Значит, все хорошо ?

да там чё-то разрулилось

Может покажусь безграмотным, но что такое "хранимки"? Хранимые процедуры (в SQL)?

скорее всего)

Может покажусь безграмотным, но что такое "хранимки"? Хранимые процедуры (в SQL)?

Да, они самые

Да, они самые

насколько мне известно, такого в монге нет, но можно сделать с помощью того же mongoose, с помощью virtuals http://mongoosejs.com/docs/api.html#Virtualtype

"Хранимки"? Да))) только хранить их надо где-то вне Монги) собственно мы хранили в текстовых файлах все наши супер js функции для агрегации данных. И версионировать удобно. Грузили их в код при запуске приложения.

Transaction.pagiante({}, { populate: { path: "some path", match: "some conditions", populate: { path: "some paath 2", match: "some conditions" } } Подскажите. Есть модель транзакция. Мне нуобходимо возвращать только те в которых оба match в populate совпадают. На данный момент первый populate работает, а второй return null (что говорит что условия match не совпали) а должно not return транзакцию.

Транзакции на базе без транзакций ? /s

Транзакции на базе без транзакций ? /s

В 4.0 завезут и транзакции в могу)

Транзакции на базе без транзакций ? /s

Вообще, возможно. Конечно, полной изоляции добиться, наверное, не возможно. Но атомарности вполне реально.

ну да, в 4.0 будет всем счастье

Добрый вечер! Парни, кто может подскажите. Например, у меня в базе данных есть баланс: 100. У злоумышленника есть доступ к базе данных, и он может изменить это значение на 10. Т.е очевидно что в цифрах хранить баланс нельзя. Что использовать? Какой алгоритм?

А не проще не давать доступов злоумышлинникам к бд?)

А не проще не давать доступов злоумышлинникам к бд?)

Дело не в этом. Например, кто-то взломал базу данных

Как вы это допустили?

Делайте нормально, нормально будет

Как вы это допустили?

Вы издеваетесь? Я просто наверняка говорю. Делайте нормально - относительно. Например твоя защита, которую ты считаешь нормальной для своего сайта, Paypal не считает защитой.

Для вас пайпал авторитет?

В рамках держитесь

Или у вас на бд не вообще никакой защиты?

В рамках держитесь

Все хорошо, дядь.

Обложите бд сслем и паролями, шардируйте и шифруйте

Добрый вечер! Парни, кто может подскажите. Например, у меня в базе данных есть баланс: 100. У злоумышленника есть доступ к базе данных, и он может изменить это значение на 10. Т.е очевидно что в цифрах хранить баланс нельзя. Что использовать? Какой алгоритм?

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

Вы можете ввернуть слой аутентификации и подписывать значение каким-то ключом

Вы можете использовать тот самый блокчейн

Вы можете использовать тот самый блокчейн

Тяжело

Вы можете использовать тот самый блокчейн

Может быть и стоит использовать

Стоит начать с модели рисков

Лучше перебдеть, чем недобдеть?)

Добрый вечер! Парни, кто может подскажите. Например, у меня в базе данных есть баланс: 100. У злоумышленника есть доступ к базе данных, и он может изменить это значение на 10. Т.е очевидно что в цифрах хранить баланс нельзя. Что использовать? Какой алгоритм?

Идиотская ситуация. Легче не допускать такого, чем творить костыль поверх воображаемой ситуации

Идиотская ситуация. Легче не допускать такого, чем творить костыль поверх воображаемой ситуации

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

Абсолютной уверенности нет)

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

Это смотря как сделаешь

Абсолютной уверенности нет)

Ну вот если нет абсолютной уверенности, нужно же думать наверняка или нет?

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

А ещё сети. И сотрудников

Ну вот если нет абсолютной уверенности, нужно же думать наверняка или нет?

У пайпала её, уверенности, тоже нет

Вам же уже сказали про модель рисков

Ну вот если нет абсолютной уверенности, нужно же думать наверняка или нет?

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

Вам же уже сказали про модель рисков

Дело в том что я должен выплачивать деньги по балансу, если вместо 100 руб кто-то напишет 1 млн, то придется платить 1млн

Норм структура

Начните с ограничения сетевого доступа

Дело в том что я должен выплачивать деньги по балансу, если вместо 100 руб кто-то напишет 1 млн, то придется платить 1млн

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

Вообще пока я проект не делал, ну заранее разбираюсь с этим, так как я Frontend разработчик. Просто я хочу сказать, даже если ограничить сети сделать всевозможное, есть 100% гарантия что хакер не сможет изменить значения?

Мне кажется что сможет. И поэтому нельзя хранить баланс в цифрах, а нужно придумать какую-ту другую модель хранения

Вообще пока я проект не делал, ну заранее разбираюсь с этим, так как я Frontend разработчик. Просто я хочу сказать, даже если ограничить сети сделать всевозможное, есть 100% гарантия что хакер не сможет изменить значения?

А, тут становится сразу все ясно. Ответ на второй вопрос выше.

Нет, ни у кого, 100% гарантии

А, тут становится сразу все ясно. Ответ на второй вопрос выше.

Окей. Мне нужно хорошо подумать. Мне кажется что что-то помимо хранения чисто цифр, можно придумать

Что вам мешает хешировать данные?

Что вам мешает хешировать данные?

Я об этом тоже думал. Пока что разбируюсь в этой теме. Но если хешировать баланс как его расхешить?

Окей. Мне нужно хорошо подумать. Мне кажется что что-то помимо хранения чисто цифр, можно придумать

Если вы фронтендер, делайте свою работу. А вопросы хранениния лучше доверить специалистам

Мне кажется вы перегибаете.

Если вы фронтендер, делайте свою работу. А вопросы хранениния лучше доверить специалистам

Ну мне все таки интересно изучать новое

Так изучайте

Обсуждение вышло за рамки этой группы

Мне кажется вы перегибаете.

Скорее всего

Окей

Спасибо

Тут вам всей темы никто не объяснит

Вероятно через $arraytoobject и push

Но это плохая идея

Лучше делать поддокументы с фиксированной структурой: {t:,v:}

Ты о чем сейчас?

Точнее к чему?

К тому, что динамическое именование ключей имеет ряд фундаментальных проблем и на мой взгляд является плохой практикой. Не важно где: в самих документах или в их агрегациях. Даты в виде ключей (а это per se не возможно, только через каст в строку) создадут больше проблем чем решат

К тому, что динамическое именование ключей имеет ряд фундаментальных проблем и на мой взгляд является плохой практикой. Не важно где: в самих документах или в их агрегациях. Даты в виде ключей (а это per se не возможно, только через каст в строку) создадут больше проблем чем решат

Ну это, да

Прост не понятно, на что