ну условно есть. С помощью магии можно сделать. Но это не важно. Проблема в том, что мне нужна возможность просто изменить тип данных. При этом даже так нельзя:
1) хватит отвечать на вопросы 2 годичной давности.
2) Переменная $_SERVER - это массив, содержащий информацию, такую как заголовки, пути и местоположения скриптов. Записи в этом массиве создаются веб-сервером. Нет гарантии, что каждый веб-сервер предоставит любую из них;
3) Его можно подделать
4) никогда не полагайтесь на REFERER
1) не подходит, так как придется знакомить базу со всякими типами денежного оборота, да и запросы такого рода меня пугают.
2) честно говоря мало знаю про UNION, в стиле, что это типа аналога JOIN, нужно будет ознакомиться. Спасибо.
3) Вы имеете ввиду взять все результаты денежного оборота, потом пройтись по ним циклом, посмотреть, что нужно еще и найти все это дело. Как-то так:
- получаем запросом 100 записей из истории
- обходим в цикле каждую запись и формируем данные для запросов. Например нужна информация для объявлений, активаций и тп.
- получаем все эти данные, затем снова прогоняемся циклом по истории и подставляем с помощью условий, что куда нужно.
Тогда будет 1 запрос на историю и по 1 запросу на "левые" сущности. Обычно их будет 2 - 3.
Я правильно Вас понял ?
jus0807: вот я тоже уже годик над этим думаю, как-то вроде работает нормально, но когда логика чуть усложняется, то все архитектура идет коту под хвост. Под усложнением логики имеется ввиду задача отображать что оплатили, зачем и когда на одной странице.
"Mysql поддерживает if" - придется дублировать логику еще на стороне базы данных. Я бы предпочел сервер баз данных вообще не трогать логикой.
"поднятие в топ: кто, "поднял в топ", '', '', 10 баксов
покупка подписки: кто, "купил подписку", "", "", 10 баксов"
Не совсем понял, но ключевой момент, ЧТО ПОДНЯЛИ В ТОМ. В нашем случае интересуют id объявлений и соответственно получить инфу, что за объявления.
"итд, заранее продумайте какие данные возможны в истории,"
Вы имеете ввиду хранить что-то типа такого:
advert_id | activation_id | ....
Тогда будет куча null, это вроде нарушает нормальную форму бд?
"И главное и самое плохое, вам придется джойнить все таблицы с данными из которых берете информацию." - не все так плохо если нужно отрендерить 100 записей на страницу и закешировать их.
"Можно обойтись без джойнов, выбрать все данные, отдельно взять из них айдишники нужные, и выбрать отдельно :) иногда это быстрей. "
Тут ситуация, что придется по любому обходить циклом и делать запросы для каждой записи. Например:
WHERE IN, чтобы получить список объявлений, которые были подняты в топ.
WHERE, чтобы узнать логин пользователя
и так исходя из условия для каждой записи, где это нужно.
"В коммент можно сохранить текстовое описание действия типа "Вася удалил запись" " - нельзя. Что если Вася сменит Логин на Петю, а Петя на Васю, тогда мы уже не сможем доверять истории.
+ Не очень хорошо хранить название таблиц и отталкиваться от них, так как изменение имени таблицы (например префикса) сломает структуру запросов.
shagguboy: это правильно, поэтому нужно написать 500 тестов и 500 методов в репозитории с названиями примерно такими: findByIdWithCategoriesImagesPropertiesValuesPaginateBySortDesc()
Mikhail Osher: вас действительно не смущает наличие лишней функции во внешнем апи. Я когда писал вопрос даже не рассматривал вариант алиасом, так как для меня вообще это неприемлимо.
Mikhail Osher: RTFM =(. В руководстве про это не упоминается. Можно указать алиас и вызывать, но тогда 2 функции будут доступны во внешнем апи, это неприемлемо.
ну тут бы я чуть-чуть подискутировал. Если бы вы мне задали вопрос: "Как называется поддержка нескольких реализаций на основе общего интерфейса. " я бы вам ответил, что-то типа фабрики.
GaserV: а какая разница ? Это запрос. Запрос он и в африке запрос. Вам нужно добавить вывод токена куда-то в мета-тег и при post-ajax запросе добавить этот самый токен в тело запроса.
sandbox.onlinephpfunctions.com/code/738bfcd1fe5bac...