и надо по этим данным чтото кешнуть

не надо форму кешировать

надо закешировать какието данные

чтобы такой же запрос быстрее отработал

если я понял задачу

при чем тут тогда пост вообще?

какая разница пост там или что другое

можно md5 хэш как ключ использовать или что-то побыстрее

¯\_(ツ)_/¯

можно

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

Ребята офтопик После обновления yum update openvpn перестал подключаться

нужно было ставить арч

tls handshake хуйня муйня чо то пишет

А что такое тлен?

это когда пиздец

TCP: connect to 122.143.11.171:1194 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

А что пиздец?

openvpn не фурычит

=(

Бросай его нафиг

есть альтернатива? )

Незнаю не заморачивался

mpd5

хотя нет, его для линукса вроде нет

Ядро после yum update не обновилось часом?

Если так то возможно требуется перезагрузка, либо модуля, либо ядра

Кто-нибудь использует uuid вместо auto_increment/sequence? В чём вы видите преимущества/недостатки?

+ - генерация в приложении - - быстродействие

(все как в гугле)

Ядро после yum update не обновилось часом?

Скорее обновилось

Скорее обновилось

Тогда я бы попробовал перезагрузиться

Просто ребутнуть поможет?)

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

Ну это моё предположение, был бы у тебя gentoo такой порблемы бы не стояло =)

Центос

:(

Текст ошибки поменялся

Народ. Базу тут проектировать начал. Думаю в таблице (Innodb онли) с юзерами первичным ключом сделать логин/никнейм. Нет ли какой веской причины почему так делать не стоит и нужно запилить uint с автоинкрементом?

+ - генерация в приложении - - быстродействие

вот, комментами выше

Почему выбираешь такой подход?

Народ. Базу тут проектировать начал. Думаю в таблице (Innodb онли) с юзерами первичным ключом сделать логин/никнейм. Нет ли какой веской причины почему так делать не стоит и нужно запилить uint с автоинкрементом?

что бы не палить email/nickname в запросах

а так - вполне адекватная штука

можно еще вместо autoincrement uuid заюзать

вообще если что - автоинкремент это рак

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

так почему бы не повесить просто уникальный индекс?

а айдишку сделать первичным ключем

(раз у тебя связи по нему идти будут)

что до "естественного ключа" - почитай у Эванса мысли на тему entity identity

проблемы автоинкремента - предсказуемость айдишки, дает некий простор для атак - требует единой точки синхронизации, плохо для распределенных систем (в том числе даже простой кейс с offline суппортом)

Я о том, что по логину 100% будет уникальный индекс. А связи я могу запилить как на логин так и на айдишник. Вопрос в том, нет ли какой скрытой от моих глаз необходимости этот айдишник вообще добавлять.

Сами эти никнеймы в любом случае навиду у всех будут.

Просто привык уже, что все ключи юнты с автоинкрементом (корпоративный недофреймворк так делал, но ему оно необходимо было ибо eav).

В общем, я так понял, фатальных проблем ключ на никнейме не несёт, иначе кто-нибудь бы ворвался как в боевиках с криком "неееееет".

ну возможность поменять никнейм

ну возможность поменять никнейм

Вроде не запланировано. Могу я в крайнем случае можно расчитывать на on update cascade?

нет

Почему?

id вообще нельзя поменять

много чего на него завязано

это практически также как поменять класс у объекта

А ведь и правда. Подумал сначала юзать никнейм ещё и в роли алиаса в url, но это ограничение на никнейм, от которого завтра может понадобиться отказаться. То есть алиас если и будет, то отдельным полем. При этом если изначально в его роли брать "стандартный" айдишник, то потом можно будет дублировать его в другое поле и позволять юзерам это поле править. А если не понадобится то и так норм.

юзай uuid и не выдумывай

А что тогда делать алиасом страницы юзера (в первом релизе её нет, а во втором будет)? /users/1234/ как-то поприличней, чем /users/427921f-2adc-11be-8aae-cf2343e5b2cf/

ERROR: S client not available

а /users/nickname еще лучше

Второй выглядит брутальнее

но все же, это же овер дофига места для хранения uuid, а есть ли в нем реальный профит, если используется одна БД?

а /users/nickname еще лучше

В том то и дело, что если никнейм будет Винстон Георгиевич Грум, то это не подойдёт. А значит нужен alias. А его нужно будет прописывать в обязательном порядке. 1234 прекрасно подойдёт для алиаса по-умолчанию.

Ребята, кто работал с Zoho CRM? Какой xml builder юзали?

Кто что использует в качестве поискового движка? На проекте использовали solr старой версии, и в связи с рефакторингом встал вопрос переехать на Еластику. Будет ли профит? Из ключевых моментов: текстовый поиск и маштабирование.

Отстал я видать. Сфинкс всё?

вот выйдет третья версия - заживём!

Аксёнов говорил что выйдет уже в прошлом декабре, видимо совсем недолго ждать осталось

мы на сфинксе живем пока что

Кто что использует в качестве поискового движка? На проекте использовали solr старой версии, и в связи с рефакторингом встал вопрос переехать на Еластику. Будет ли профит? Из ключевых моментов: текстовый поиск и маштабирование.

Эластика это либа?

а вообще да, у меня тоже сфинкс

сам по себе Эластик - огонь

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

Эластика это либа?

нет, я про Elastic Search

у сфинкса куча проблем если у тебя данных много

ElasticSearch - идеальный

но у его свои особенности

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

ну и далеко не всегда нормально стеммер работает

у сфинкса есть шардинг?

Данных много, еще и частые индексации

кто-то еще пользуется сфинксом?

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

опять же с третьей версии будет)

шардинг в целом нужен только тогда, когда у тебя данные на сервере не помещаются в память. В частности на дешевом сервере с < 32Gb RAM

ты хоть видел в каком состоянии сейчас третья версия?

и в каком состоянии там шардинг?

я нет, но Аксёнов говорит что скоро альфа, а там и глянуть можно будет

вообще-то ещё к хайлоуду должна была быть альфа

http://db-engines.com/en/system/Elasticsearch%3BSphinx

в смысле к конференции Highload