LINUX.ORG.RU

[mongodb] Странный выхлоп mongodb


0

1

Доброго дня. Внезапно потребовалось использовать mongodb. Встал перед проблемой что не могу сделать работающий запрос через REST. Собственно запрос: curl http://127.0.0.1:28017/db/collect/?filter_uid=5b7ff430d6ff06378d2292d1ad2b4af8

Выхлоп:

{ «offset» : 0, «rows»: [

],

«total_rows» : 0 , «query» : { «uid» : 5 } , «millis» : 33 }

Почему подрезался uid? Такое происходит с большинством ключей, но не со всеми. При этом если делаю подобный запрос через шел - шел рушиться.

Экспериментальная DBMS. Да,да гугл может позволить себе юзать в продакшене, у них полно денег и лучшие инженеры.

psp13 ()
Ответ на: комментарий от psp13

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

baboon ()
Ответ на: комментарий от iSage

Обьясню. На вход нужен json. В твоем случае поле скастовалось в int, поскольку без кавычек

iSage ★★★★ ()
Ответ на: комментарий от psp13

монга просто супер, очень жаль людей типа тебя, просто у всего есть свое применение, и у монги тоже. думаешь твой код стабильнее монги будет в любом ее ночном билде? сомневаюсь.

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

После redis mongo меня тоже расстраивает. У них целевое назначение конечно разное, но монго уж слишком не поворотлива для nosql db. Вообщем аккуратно работать с ней надо.

baboon ()
Ответ на: комментарий от trashymichael

Мой код не падает. Да и зря вы меня жалеете - меня PostgreSQL устраивает на 100%. А ваше монго поддерживает транзакции только в пределах одной таблицы. Да здраствуют inconsistent data - вобщем то вся философия ваших новомодны nosql именно и является ничем иным как пропагандой наплевательского отношения к хранимым данным. За SQL стоит математическая теория а за вашими nosql-поделками что стоит? JSON?

psp13 ()
Ответ на: комментарий от psp13

Да здраствуют inconsistent dat

Да здравствует EAV и извращение при попытке запихнуть в реляционную модель то, что для неё не предназначено.

anonymous ()
Ответ на: комментарий от anonymous

В постгре есть hstore. Так что делай вдоль, это ортогональные вещи.

dizza ★★★★★ ()
Ответ на: комментарий от psp13

против вашго sql и вашего постгре я ничего не имею и сам постоянно использую. но вы так говорите как а что стоит за вашими файлами? plain text?

trashymichael ★★★ ()
Ответ на: комментарий от dizza

В постгре есть hstore.

А разве hstore умеет что-то, кроме строк?

anonymous ()
Ответ на: комментарий от anonymous

Никакого извращения в EAV не вижу. Это оно для тех извращение кто не смог осилить нормализацию и ушёл клепать дырявые поделки на новомодных недотехнологиях. Кроме того что может быть извращённее inconsistent data. Или вам уже совсем наплевать на вопросы security & reliability и всё в чём вы заинтересованы - что бы у вас код выглядел ООПистически красиво?

psp13 ()
Ответ на: комментарий от psp13

Никакого извращения в EAV не вижу.

Ну-ну. Реляционная структура в EAV далека от здравого смысла. Кроме того, массовые JOIN-ы дают значительно проседание производительности.

Кроме того что может быть извращённее inconsistent data.

С чего это в документ-ориентированных БД будет inconsistent data? Ну да, если мозг проеден EAV, то можно накрутить какие-нибудь сотни связей на пустом месте, и получить эту ситуацию, но зачем?

что бы у вас код выглядел ООПистически красиво?

Б-же мой, человек борется с ООП, но при этом приемлет кривейший EAV.

anonymous ()
Ответ на: комментарий от anonymous

Да мне нравится EAV и я борюсь с тотальной опизацией. А что все должны боготворить ООП?

Прошу привести реализацию в mongo не поддерживающем транзакций на несколько таблиц реализацию такой схемы:

[code=sql] create table users ( id bigserial primary key, username varchar(64) not null unique, balance numeric(16,2) CHECK (balance > 0.00) ); create table transactions ( id bigserial primary key, source bigint references users (id), destination bigint references users (id), amount numeric(16,2) not null CHECK (amount > 0.00), created_on timestamp not null ); [/code]

Как объединить 2 таблицы в одну что бы можно было осуществить в транзакции `INSERT INTO transactions...` + `UPDATE users SET balance = ...`? Только не надо про ращётные периоды. Это удел советских бухгалтеров. Я что то не слышал что бы paypal или moneybookers прекращали работу что бы закончить ращётный период. Прикажите удалить users.balance и перещитывать транзакции за многие годы? Просвятите идиота с мозгом разъеденным кривым SQL как в вашей богоугодной монге такое сделать. Жду ответов.

psp13 ()
Ответ на: комментарий от psp13

Что ж за идиоты зделали этот TeX paragraphs по умолчанию!!!!!!

 create table users ( id bigserial primary key, username varchar(64) not null unique, balance numeric(16,2) CHECK (balance > 0.00) ); create table transactions ( id bigserial primary key, source bigint references users (id), destination bigint references users (id), amount numeric(16,2) not null CHECK (amount > 0.00), created_on timestamp not null ); 
psp13 ()
Ответ на: комментарий от psp13

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

jessey ()
Ответ на: комментарий от psp13

Тащемта область применения nosql и близко не пересекается с задачами требующими ACID, так что расслабьтесь, все хорошо.

redixin ★★★★ ()
Ответ на: комментарий от psp13

Прикажите удалить users.balance и перещитывать транзакции за многие годы?

Не скажу за монго, но в couchdb результаты views, в общем-то, всегда кэшируются в готовом виде, и там этот подход является быстрым, простым и правильным.

anonymous ()
Ответ на: комментарий от redixin

Тащемта область применения nosql и близко не пересекается с задачами требующими ACID, так что расслабьтесь, все хорошо.

Ну ладно, убедили - для бложика пойдёт ваш nosql.

psp13 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.