| 1.1, бедный буратино (ok), 11:52, 12/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Доступ к БД производится при помощи протокола HTTP с использованием RESTful JSON API, что позволяет обращаться к данным в том числе из выполняемых в браузере web-приложений.
А как там с правами доступа? Приложение только на couchdb + js построить реально?
И как быть с тем, что браузеры не дают выполнять json кросдоменно. Оно умеет оборачивать в jsonp?
| | |
| |
| 2.6, RKAKriK (?), 13:08, 12/04/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А как там с правами доступа?
Все в порядке. Система немного непривычная, но вполне логичная:
http://guide.couchdb.org/draft/security.html
http://wiki.apache.org/couchdb/Security_Features_Overview
> Приложение только на couchdb + js построить реально?
Вполне. Собственно на это и было рассчитано. До моего знакомства с каучом я жс вообще не признавал как что-то серьезное, но сейчас мое мнение изменилось.
> И как быть с тем, что браузеры не дают выполнять json кросдоменно. Оно умеет оборачивать в jsonp?
Умеет, но все-же там больше рассчитано, что само веб-приложение будет лежать в самом кауче. В смысле каучдб не столь база данных, сколько целиком сервер приложений. К примеру, у нас на кауче крутится система сбора данных со счетчиков электроэнергии. Сами счетчики по https используя только rest шлют показания на кауч, кауч их сохраняет в базу и он же эти данные обрабатывает, там же лежат html'ки с жавоскриптом которые уже обработанные данные показывают в красивом и удобном виде.
| | |
| |
| 3.8, Аноним (-), 18:09, 12/04/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Сами счетчики по https используя только rest шлют показания на кауч, кауч их сохраняет в базу и он же эти данные обрабатывает, там же лежат html'ки с жавоскриптом которые уже обработанные данные показывают в красивом и удобном виде.
Если сюда забредут юные борцы за юниксвей, они обязательно возмутятся по поводу СУБД со встроенным веб-сервером :)
| | |
| |
| 4.9, бедный буратино (ok), 18:51, 12/04/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Если сюда забредут юные борцы за юниксвей, они обязательно возмутятся по поводу СУБД со встроенным веб-сервером :)
А что с юниксвеем-то?
| | |
|
| 3.15, мимопроходил (?), 15:47, 14/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Вполне. Собственно на это и было рассчитано. До моего знакомства с каучом
> я жс вообще не признавал как что-то серьезное, но сейчас мое
> мнение изменилось.
Интересно, что так повлияло на ваше мнение, может невозможность code reuse во вьюхах? Или необходимость поддерживать ссылочную прозрачность в языке, который для этого не пригоден, мягко говоря?
| | |
| |
| 4.17, тожемимопроходил (?), 23:12, 15/07/2013 [^] [^^] [^^^] [ответить]
| +/– | |
1. Couch поддерживает code reuse в view через CommonJS-подобные require(). В старых версиях не составляло труда написать макросы которые вставляли исходники прямо в текст view – ведь view – всего лишь данные дизайн-документа.
2. В Clojure, Scheme и Common Lisp (и даже в OCaml!) тоже нет referential transparency, к слову. Как и в большинстве популярных ЯП вообще кроме Haskell, который популярным можно назвать с некоторой натяжкой.
Другое дело, что у концепции CouchApp есть серьёзные ограничения, обойти которые часто очень сложно: к примеру, невозможность write-only настройки авторизации без дополнительного прокси-сервера, или параметризированные view, или простейшие отношения многие-ко-многим, типа простейших тэгов, для которых необходимо поднимать дополнительный отдельный от коуч индекс и т.д..
| | |
|
|
| 2.10, Аноним (-), 20:31, 12/04/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> А как там с правами доступа?
Фигово. В пределах одной базы разграничение на доступ к записям пользователям сделать нельзя. То есть читать писать могут все кто авторизовался. Выход - создавать на каждого пользователя свою БД и да их может быть много, например если в БД хранить почту пользователей. И делать общие БД с которыми синхронизировать пользовательские БД если нужны общие данные.
| | |
|
| |
| 2.4, o (?), 12:52, 12/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
Mongo она по сути inmemory, во всяком случае нужно обязательно тестить ситуации когда данных будет больше чем оперативы.
А тут база на дискею
В этом смысле CouchDB ближе в всем знакомым и понятным SQL базам.
| | |
| |
| |
| 4.14, мимопроходил (?), 15:41, 14/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
Скорее всего гражданин Кац упарывался чем-то тяжелым и тужился написать кауч на С++. Потом, во время реабилитации, методом херак-херак и в продакшен наваял вполне работающий сервер на Эрленге. Теперь вот, видать, опять сорвался, потому как сейчас пилит каучбейс уже на Си, слив каучДБ орлам из апача.
| | |
|
| 3.11, northbear (??), 23:19, 12/04/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Mongo она по сути inmemory,
Приснилось, что-ли? Или трава крепкая попалась?
| | |
| |
| 4.16, o (?), 10:51, 15/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
Вот именно из за такой квалификации среднестатистического разработчика и не стоит использовать монгу без предварительного нагрузочного тестирования. Про память можно посмотреть в гугле по "mongodb memory limit".
Тут можно сказать типа руки кривые если то чьи это проблемы? Проблемы получаются заказчика сервиса, а косяк монги в том что ее пиарят умалчивая серьезные особенности (читай недостатки) данной БД.
| | |
|
|
| 2.12, Имяноним (?), 23:23, 12/04/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Zachem? Esli est MongoDB!
ну как минимум наверно по тому что MongoDB не может обновить атомарно сразу 2~3 документа, по принципу "либо изменятся сразу все, либо не изменится ни один" :-).
| | |
|
|
