@phpgeeks - страница 715 - Telegram web archive

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

The Ant

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

The Ant

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

Juri

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

Sergey

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

The Ant

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

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

The Ant

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

Juri

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

The Ant

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

The Ant

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

The Ant

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

Juri

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

Juri

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

The Ant

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

Anonymous

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

Anonymous

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

Anonymous

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

Alexandr

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

Roman

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

Roman

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

Sergey

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

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

Alexandr

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

Anonymous

Лечииись

Sergey

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

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

Alexandr

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

Sergey

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

Alexandr

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

Sergey

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

Sergey

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

Anonymous

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

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

Sergey

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

Anonymous

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

Sergey

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

Alexandr

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

Alexandr

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

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

Alexandr

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

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

Sergey

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

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

Sergey

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

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

Alexandr

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

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

Anonymous

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

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

Anonymous

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

Anonymous

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

старий

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

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

Alexandr

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

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

Alexandr

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

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