нет

Спасибо!

Бот бесправен:(

Ребята, стоит получть за 600р ISIC карту, а потом профессиональные версии на jetbrains по ней?

Sublime Text only=)

Ну блин, я не хочу ставить на ноутбук еще и couchdb

Ну блин, я не хочу ставить на ноутбук еще и couchdb

не хочешь - не ставь.

Ну не на сервере же тестировать

А remote исполнение только в профессиональной версии

Сублайм и rmate

класс- прокладка, который на локальном хосте подменяешь на такой же, но с {}.

Хотя я вот счас на ноуте все место расчищаю, а то есть пара баз на 50гб, а на развернуть пока места нет

ну и да, я ничего не знаю про couchdb, но на винде у меня redis занимает чуть меньше трех мегов с тестовой базой на сколько-то там записей.

Ребята, вопрос Как лучше организовать добавление новых пользователей, а точнее как получать количество зарегистрированных: 1) получать у БД спиок пользователей и брать от него len 2) то же самое, но только 1 раз при запуске, а потом инкрементировать 3) создать в БД отдельный "элемент", в котором находится количество пользователей

Чорт, так у БД же должен быть встроенный len...

БД какая?

CouchDB Я уже увидел, там есть в /db/_all_docs -> total_rows

А, ну ок.

Сам спросил -- сам ответил)

Метод уточки, ага.

А селект не круто?

Селект каунт (ид) вхере...

select count(*) from users же

а вообще я вангую что твой вопрос связан с "какой айди прикрутить к новому юзеру"

если так -- сделай айди юзера инкрементальным и праймери ключом, уникальным

и если все сделать верно то это даже безопасно

нет у него инкременталього праймери ключа, couchdb же.

а вообще я вангую что твой вопрос связан с "какой айди прикрутить к новому юзеру"

Для этого не совсем безопасно юзать count на число юзеров

ааа, я сорри, невнимательность

Там же написано, ему нужно просто считать число юзеров

Хотя не ясно

Ребята, вопрос Как лучше организовать добавление новых пользователей, а точнее как получать количество зарегистрированных: 1) получать у БД спиок пользователей и брать от него len 2) то же самое, но только 1 раз при запуске, а потом инкрементировать 3) создать в БД отдельный "элемент", в котором находится количество пользователей

А с какой целью тебе нужно именно получать число юзеров при добавлении новых?)

А с какой целью тебе нужно именно получать число юзеров при добавлении новых?)

Получить user_id

Тогда не используй для этого count ни в коем случае

Да и сторонняя переменная тоже не прокатит

Они не удаляются

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

Либо рейс и привет

Да и сторонняя переменная тоже не прокатит

Это count на велосипедных костылях

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

Ну вот тот же vk

В вк для этого используется автоинкремент в бд

Я просто не совсем уверен, что в couch есть аналог транзакцией

ций*

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

http://stackoverflow.com/questions/5073343/approaches-to-generate-auto-incrementing-numeric-ids-in-couchdb

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

Оп, а вот это уже да...

Race Condition это называется

Инкрементальные айдишники так уж принципиально нужны?

Вообще я подумываю отказаться от них

в пользу uuid?

Еще не знаю в пользу чего

Почему бы и не uuid + кастомная ссылка

В твиттере же нет инкрементального ида

кстати, https://habrahabr.ru/post/265437/

https://habrahabr.ru/post/31632/

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

кстати, https://habrahabr.ru/post/265437/

В той бд впринципе нет автоинкремента

Он его собирался вручную реализовывать

а

этого лучше не делать, пожалуй

чувак, заведи две базы. юзеров складывай в обычный sql, а связку токен-юзер храни в key-value.

uuid просто создан для таких вещей, ну очень мал шанс что совпадут

чувак, заведи две базы. юзеров складывай в обычный sql, а связку токен-юзер храни в key-value.

И стоит ли игра свеч?

Я чуток по-другому сделаю

ERROR: S client not available

И стоит ли игра свеч?

не знаю, не я же couchdb в проект притащил

что такое вообще этот кауч и зачем он нужен?

Да я еще не прикрутил его

Можете любой другой советовать)

Очередное документ-ориентированное хранилище

А-ля монга

это такая база, в которой Json удобно хранить переменной структуры. В двух словах.

постгрес

Можете любой другой советовать)

Зависит от задачи

умеет хранить и json, и обычные реляционные данные

Сейчас, было где-то выше

с версии 9.5, кажется

или 9.4, не помню

недавно появились улучшения на этот счёт

другое дело, чем не хватает обычной реляционной базы

другое дело, чем не хватает обычной реляционной базы

+

Ребята, вопрос Стоит ли поднимать *sql* только для хранения токенов -> id ?

Ну пока у меня используется shelve

Но его же нельзя сделать разделенным между процессами

Набираю текст

Нужно чтобы было нечто, куда можно писать и откуда читать связку token - vk_id - name - ... Причем делать это разными процессами, один только добавляет новые связки, другой читает существующие и редактирует их поля (может любое, но не vk_id) Вместо ... пока только color, возможно еще будут, но это вроде не важно

Максимум 1000, и то маловероятно При запуске будет пробегаться по всей базе Потом в процессе работы редактировать существующие поля может... в крайнем случае раз 10 за секунду Добавлять новые и считывать и того реже, где-то раз в секунд 20-30, но пусть будет раз в 3 секунды

redis?

Ну, это если выборка только по токену

Погодите-ка А почему бы не сделать сохранение пользователей по vk_id?

зафиксируй список полей, подними *sql И не мучай себя и других.

обычно для данных типа "пользователь" куда больше подходит всё же обычный реляционный сторедж

как там было, явное лучше неявного.

особенно если там три с половиной поля :)

как там было, явное лучше неявного.

или подразумеваемого?

То есть пользователи из вк будут иметь ключ `"vk"+vk_id`