mongodb выбрать документ с определенным (lt, gt) количеством определенных элементов поля-массива

0

1

тоесть, вот $size например, но нельзя сделать {$size: {$lte, задача же — выбрать одним запросом (нужно для атомарного обновления) документ в котором количество определенных элементов массива не превышает заданный порог

можно сделать $elemMatch & $size но аргумент для $size — обычное число, мне же нужно там «больше-меньше», еще проще говоря

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

Ссылка

←	Web-based SIP-клиент (или что-нибудь в этом духе). Как организовать связь с его помощью?

Python 3 + WEB

→

тут уж я могу, наверное, сделать $or´ов столько, каков лимит, но это как-то тухло пахнет

trashymichael ★★★
(27.05.13 14:42:05 MSK) автор топика
Последнее исправление: trashymichael 27.05.13 14:42:37 MSK (всего исправлений: 1)

http://docs.mongodb.org/manual/reference/operator/where/#op._S_where ?

Y ★★
(27.05.13 16:50:38 MSK)

Ссылка

Ответ на: комментарий от trashymichael 27.05.13 14:42:05 MSK

mongos> db.tratata.find()
{ "_id" : ObjectId("51a3589fea6a9417f9a12101"), "r" : [ 1, 2, 3, 4, 5, 6, 7, 1, 1 ] }
{ "_id" : ObjectId("51a358a2ea6a9417f9a12102"), "r" : [ 1, 2, 3, 4, 5, 6, 7, 1 ] }
{ "_id" : ObjectId("51a358a4ea6a9417f9a12103"), "r" : [ 1, 2, 3, 4, 5, 6, 7 ] }
{ "_id" : ObjectId("51a358a8ea6a9417f9a12104"), "r" : [ 2, 3, 4, 5, 6, 7 ] }
mongos> db.tratata.find({ $where: function() { var c = 0; this.r.forEach(function(el) { if (el == 1) { ++c; }}); if (c > 2) return true; return false; } })
{ "_id" : ObjectId("51a3589fea6a9417f9a12101"), "r" : [ 1, 2, 3, 4, 5, 6, 7, 1, 1 ] }

Y ★★
(27.05.13 16:55:58 MSK)

Ответ на: комментарий от Y 27.05.13 16:55:58 MSK

ну про Where я читал но че-то как-то сомнения терзают, а у меня это все еще и в ORM завернуто, там конечно есть этот where и exec_js но феншуй мой страдает от этого, или вполне нормальная ситуация?

trashymichael ★★★
(27.05.13 17:22:11 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 17:22:11 MSK

и, как я говорил, мне это нужно для атомарного апдейта, не выйдет ли так что пока эта функция будет делать Where другое подключение его уже сделает? наверное сам не знаю о чем говорю ((

trashymichael ★★★
(27.05.13 17:24:19 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 17:22:11 MSK

По-моему, в данной ситуации нормальный вариант. Можно ещё подумать об оптимизации структуры данных в самой бд.

exec_js в данном случае очевидно лишнее.

Y ★★
(27.05.13 17:26:32 MSK)

Ссылка

Ответ на: комментарий от trashymichael 27.05.13 17:24:19 MSK

findAndModify делает атомарный апдейт.

http://docs.mongodb.org/manual/reference/command/findAndModify/

Y ★★
(27.05.13 17:27:17 MSK)

Ответ на: комментарий от Y 27.05.13 17:27:17 MSK

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

trashymichael ★★★
(27.05.13 19:24:06 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 19:24:06 MSK

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

trashymichael ★★★
(27.05.13 19:31:47 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 19:24:06 MSK

Правильно. По-моему, на текущий момент это не верно абсолютно, но можно всегда проверить.

В 2.4 они перешли на V8 и обещают «improved concurrency for JavaScript operations».

Previously, MongoDB operations that required the JavaScript interpreter had to acquire a lock, and a single mongod could only run a single JavaScript operation at a time. The switch to V8 improves concurrency by permitting multiple JavaScript operations to run at the same time.

Y ★★
(27.05.13 19:36:27 MSK)

Ссылка

Ответ на: комментарий от trashymichael 27.05.13 19:31:47 MSK

Это хороший вариант. В одном из своих Use Case они по-моему предлагают что-то подобное. Можно пересмотреть организацию документа более глобально. Например, хранить элементы разных типов в отдельных массивах. Так не придётся каждый раз инкрементировать счётчик. Конкретное решение диктует характер данных и выполняемых над ними операциями.

Y ★★
(27.05.13 19:39:02 MSK)

Ответ на: комментарий от Y 27.05.13 19:39:02 MSK

данные таковы что есть игрок и у него есть строения, так как особых характеристик у них нет, думалось просто хранить их в вид е объектов {name: 'тип здания', created_at: таймштамп} массива, но на разные здания есть разные ограничения по количеству, тоесть нельзя иметь больше 5 зданий типа1 и т.п., выходит тут и отдельные массивы на тип здания не спасут, т.к. все равно все в $size упирается, возможно действительно пересмотреть структуру вообще нах

trashymichael ★★★
(27.05.13 19:54:20 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 19:54:20 MSK

но как тогда мне лучше поступить, делать пропортю на каждое здание с флагом «построенно» штоль?

trashymichael ★★★
(27.05.13 20:44:11 MSK) автор топика

Ответ на: комментарий от trashymichael 27.05.13 20:44:11 MSK

или придумать что-то вообще из ряда вон выходяще хитрое, т.к. в основном здание либо есть либо его нет, но в некоторых случаях их может быть несколько, а в некоторых там могут быть дополнительные поля (У зданий), как-то красиво хотелось это сделать все, эх, врятли лыжи не едут

trashymichael ★★★
(27.05.13 20:45:39 MSK) автор топика

Ссылка

Ответ на: комментарий от trashymichael 27.05.13 19:54:20 MSK

Почему не спасут? Отдельные массивы на каждый тип здания и size по этому массиву.

Y ★★
(28.05.13 12:37:53 MSK)

Ответ на: комментарий от trashymichael 27.05.13 20:44:11 MSK

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

Y ★★
(28.05.13 12:39:16 MSK)