это был не обычный хостинг, а достаточно дорогой сервер

ну может mysql криво настроен был. это не совсем верное хранение, но оно не плохое. альтернативу предложите?

классическая схема many-to-many для выборки внутри категории работает быстрее

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

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

иначе можно смело утверждать, что разрабы кликхауса лошки какие-то

как я уже и писал выше для сбора статы отлично подойдет вот такая схема. 1 таблица с тремя полями, id материала, дата, каунтер. все. больше нчиего не нужно, на все три поля повесить индексы. работать будет очень быстро

А на каунтер зачем индекс?

как я уже и писал выше для сбора статы отлично подойдет вот такая схема. 1 таблица с тремя полями, id материала, дата, каунтер. все. больше нчиего не нужно, на все три поля повесить индексы. работать будет очень быстро

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

как там будет поддержка этой системы происходить его это не волнует )

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

ну под клиентом я подразумеваю Рината

он спросил 2 варианта, я же попытался ему намекнуть что вариант 1 бред сивой кобылы

просто напомню

это не просто бред... это жуть

интересно, как быть если материал появился в середине месяца)

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

Приветствую народ

Кто нибудь с вордпресс работает?

Не могу понять как выводить одну вещь

как в rest api отразить операции блокировки/заморозки аккаунта (два разных действия, которые меняют статус в базе) ? ... если делать PATCH /users/{userId} и передавать нужный статус, то клиентам придется знать о деталях реализации ... если делать PATCH /users/{userId}/block, то это типа нарушение rest-принципов)

Всем привет

http://t.me/CashRobotsBot?start=TKrLHQng

Зайдите пожалуйста мне нужно 6 рефералов собрать

лол

бля, че только тут не увидишь

Заходи

да уж, настоящий phpGeeks чат )

надо только phpGeeks 7.1 - We WON! назвать

как в rest api отразить операции блокировки/заморозки аккаунта (два разных действия, которые меняют статус в базе) ? ... если делать PATCH /users/{userId} и передавать нужный статус, то клиентам придется знать о деталях реализации ... если делать PATCH /users/{userId}/block, то это типа нарушение rest-принципов)

Передавай статус текстом

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

Лечииись

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

У тебя клиент и так знает реализацию, т.к. посылает данные конкретной структуры

нет, клиент просто хочет отправить запрос на сервер "заблокируй аккаунт с id 12345" ... клиенту должно быть всё равно как это делается

Но он же знает куда посылать и что посылать

вот о том и вопрос, как установить контракт на такое действие в рамках rest-парадигмы )

Передавай статус текстом

url это тоже часть реализации

вот о том и вопрос, как установить контракт на такое действие в рамках rest-парадигмы )

ты слишком буквально воспринимаешь REST принцип

Тебя же не смущает то что клиент посылает на /users

Это не парадигма и не паттерн, а принцип взаимодействия

Клиент может хочет посылать на /clients, но ты показываешь ему свою реализацию

я могу сделать PATCH /users/{uesrId} (body:{status: "blocked"}) ... но тогда для заморозки у меня будет та же точка входа только status: "frozen" ... что выглядит сомнительно

Клиент может хочет посылать на /clients, но ты показываешь ему свою реализацию

это не реализация, это интерфейс

Это не парадигма и не паттерн, а принцип взаимодействия

и мне хочется знать, как решается данная задача в рамках данного принципа взаимодействия ... или понять, что в рамках rest это нерешабельно)

я могу сделать PATCH /users/{uesrId} (body:{status: "blocked"}) ... но тогда для заморозки у меня будет та же точка входа только status: "frozen" ... что выглядит сомнительно

Нормально выглядит

я могу сделать PATCH /users/{uesrId} (body:{status: "blocked"}) ... но тогда для заморозки у меня будет та же точка входа только status: "frozen" ... что выглядит сомнительно

https://dev.twitter.com/rest/public/search посмотри на параметр filter

https://dev.twitter.com/rest/public/search посмотри на параметр filter

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

и мне хочется знать, как решается данная задача в рамках данного принципа взаимодействия ... или понять, что в рамках rest это нерешабельно)

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

ключивое слово "функционально"

т.е. какую логику мы будем абстрагировать в коллбеках

и мне хочется знать, как решается данная задача в рамках данного принципа взаимодействия ... или понять, что в рамках rest это нерешабельно)

ты же можешь писать users/{id}/block и отправлять туда данные хоть постом

ты же можешь писать users/{id}/block и отправлять туда данные хоть постом

и это будет rpc, а не rest

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

разница лишь в контроле доступа над операциями, хотя в будущем может и увеличиться ... смешивать не вариант ... абстрагировать нужно именно на уровне URI ... проблема в том, что PATCH /user/{userId} - это обновление данных юзера ... и по идее, должно использоваться именно тогда, когда клиент хочет обновить данные юзера, ничего кроме ... потому и для более высокоуровневых доменных операций (которые могут включать, а могут и не включать обновление данных ресурса) использовать этот URI сомнительно

Кто бы как реализовывал роутинг для cms?

Кто бы как реализовывал роутинг для cms?

Писал бы cms на фреймворке)

Писал бы cms на фреймворке)

Ну ок, а как бы на фреймворке решил проблему бесконечной вложенности url?)

Ну ок, а как бы на фреймворке решил проблему бесконечной вложенности url?)

в смысле?

в смысле?

Ты будешь для каждой страницы контроллер заводить? Или экшн? Или есть еще варианты?

Ты будешь для каждой страницы контроллер заводить? Или экшн? Или есть еще варианты?

а зачем тебе бесконечная вложенность?

а зачем тебе бесконечная вложенность?

Cms мне кажется должна иметь бесконечную вложенность

Cms мне кажется должна иметь бесконечную вложенность

однажды тебя браузер с сервером поймают за too long url

ERROR: S client not available

Cms мне кажется должна иметь бесконечную вложенность

как насчет перекреститься?

однажды тебя браузер с сервером поймают за too long url

Ну в разумных переделах все

как насчет перекреститься?

Пробовал? Помогло?

Пробовал? Помогло?

ну таких идей ко мне не приходилл

ну таких идей ко мне не приходилл

Ясно

разница лишь в контроле доступа над операциями, хотя в будущем может и увеличиться ... смешивать не вариант ... абстрагировать нужно именно на уровне URI ... проблема в том, что PATCH /user/{userId} - это обновление данных юзера ... и по идее, должно использоваться именно тогда, когда клиент хочет обновить данные юзера, ничего кроме ... потому и для более высокоуровневых доменных операций (которые могут включать, а могут и не включать обновление данных ресурса) использовать этот URI сомнительно

Если честно, то лично я не вижу проблемы. Но признаю, что вопрос может быть вполне резонным, просто потому что мы по разному на задачу смотрим. В конце концов я программист, а не архитектор)

Если честно, то лично я не вижу проблемы. Но признаю, что вопрос может быть вполне резонным, просто потому что мы по разному на задачу смотрим. В конце концов я программист, а не архитектор)

согласен, мб и нет проблемы) ... но стало интересно как это решают другие)

Писал бы cms на фреймворке)

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

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

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

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

И все эти пути ты естественно регаешь вручную

100500 путей

И все эти пути ты естественно регаешь вручную

Да

Да

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

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

А клиент тут причём?

А клиент тут причём?

Ну не клиенту а манагеру которая будет работать на этой cms и добавлять странички на сайт

Ну не клиенту а манагеру которая будет работать на этой cms и добавлять странички на сайт

Ну ты пишешь posts/create

posts/show

posts/show

Site.ru/htrc/gdbn/fbnj/hnng/ngdt/g вот такой url нужно сделать например

Site.ru/htrc/gdbn/fbnj/hnng/ngdt/g вот такой url нужно сделать например

вот и я спрашиваю, зачем?)

вот и я спрашиваю, зачем?)

По тз прописано)

По тз прописано)

ну у тебя есть posts/category/slug

ну у тебя есть posts/category/slug

И?

И?

и подставляешь туда wildcards

И?

вот, например, пример для ларавела

Route::get('posts/{categories}', 'PostController@categories') ->where('categories','^[a-zA-Z0-9-_\/]+$');

Вот это уже ближе похоже на ответ, спасибо, буду дальше думать

вот, например, пример для ларавела

представь себе: https://site.com/shop/electronics/computers/komplectyuschie/hard-drives/3.5/western-digital/black/102888395

представь себе: https://site.com/shop/electronics/computers/komplectyuschie/hard-drives/3.5/western-digital/black/102888395

Вот для таких случаев у тебя есть решение?

так этот путь строится по цепочке категорий

вложенных друг в друга