Хм, даже не подумал в эту сторону. Хотя и видел переменную сессии.
Во всех платежных системах принцип один.
В своей базе фиксируете желание пользователя заплатить/оплатить заказ.
Отправляете на страницу оплаты с указанием за что конкретно платится.
Есть подвиды, когда нужно до этого дернуть апи платежной системы и зарегистрировать там , получив конкретную ссылку, уточняющий параметр.
От платежной системы приходят два вызова.
Перед началом списания денег, что вы готовы их принять(зафиксировать покупку). Обычно такой хук тупо отвечает. Да давай деньги быстрей.
Буквально через секунду летит второй вызов (я его авизкой называю)
Тебе пришли деньги. Столько то. И вот в этот вызов платежные системы дают обычно протянуть дополнительные поля. Полезную нагрузку от кого и за что оплата. Обычно уточняющим выступает номер заказа.
При приходе авизо делаются все проверки. Точно платежная система ? сумма правильная ? и т.п. Но если отправителя обязательно проверять,
то платеж можно просто зафиксировать и оставить человеку окончательную роль принятия решения, что с оплатой все хорошо.
Т.е. Если не сошлось в копейках из-за конвертации код может сам прощать или помечать заказ что оплата была в таком то размере.
А вот тому, что приходит с гет параметрами при редиректе пользователя я бы не верил.
это просто аккорд из двух кнопок. Crtl+L
Форматирование. Отступы и т.д. Давно не показатель качества кода.
Современные среды разработки даже проведут более глубокий анализ за Вас.
Все что нужно это понимать. По делу или нет ругается .
Иногда предупреждения все же приходиться давить.
А в правом углу зеленая галка может быть и у неправильно работающего в плане бизнес логики кода.
Самый страшный бан для андроид разработчика, это когда по цепочки банятся все гугл аккаунты, которые гугл посчитал, как используемые одним человеком.
В общем Вас все равно вычислят и забанят телефоны всей семьи ;)
Забыл написать. Сам по себе SQL это тоже можно сказать язык программирования.
Хотя бы минимально с ним разобраться, чтобы понимать, что происходит под капотом более высокоуровневой обертки.
Основные команды 4 : select (тут целая вселенная ), insert, update, delete
Академически в основе SQL лежит реляционная алгебра множеств. Но если не вуз. То всякие кортежи и пересечения множеств можно наверное опустить. www.mysql.ru/docs/man/SELECT.html
Вам потребуется LIMIT смещение, сколько_брать
Берете любой учебник и делаете поправку, что в большинстве они написаны на примерах mysql_что-то
а сейчас все перешли на mysqli_
объединение таблиц.
where a.id = b.id_a эквивалент left inner join
left outer join - все записи слева и поля из второй таблицы по ключу или нулл значения.
еще есть правое объединение, но я его практически за свою жизнь не использовал.
в запрос таблица может входить больше одного раза. В этом случае ей присваивается алиас.
таблица поставленных значений войдет в запрос дважды.
Первый раз чтобы найти ид за что поставлены оценки.
соединиться с таблицей аналогов, чтобы получить за что еще можно голосовать.
теперь открытое соединение(left outer) с таблицей оценок.
Там где голосовал будут значения. А за что еще нет останется нулами.
третий джоин закрытый (left inner) . Ключ inner можно не писать (как дефолт)
остается к запросу добавить условия отбора записей. К первому алиасу оценок по ид пользователя, ко второму , что значения нет.
И в части перечисления полей, что нас интересует только ид и название из товаров.
первый коммент к моему ответу
Slavik12 Slavik12 Автор вопроса
не, я с БД работаю. И в БД есть столбец, который отвечает делали ли это задание сегодня. И раз в сутки значение должно сбрасываться, чтобы на след. день его снова сделать.
У вас в базе сейчас поле целого типа / булевого / enum
То есть Вы просто фиксируете делал или нет сегодня.
select * .... where delal=0
а) Можно фиксировать когда делал
select * ... where delal<'2020-03-06 23:36:00' - минус сутки
б) Можно писать в поле до какого времени нельзя делать еще раз
select * ... where freeze
Если нужно показывать все, а не только доступные, то
вместо прямого обращения как раньше было к полю делал_или_нет
теперь вызывайте псевдо-гетер, который сравнит поле даты с текущем временем и вернет как раньше булево
Но для задачи топик стартера . Показать задания, которые не делали сегодня .
Инструмент малость не подходящий. Костылить черте что вместо правильной организации базы данных. Булево поле поменять на дату-время и проблема решена.
другой вариант поле недоступно до.
При выполнении к текущему дате-времени прибавляете сутки/неделю.
В этом случае select будет проще (если они у вас в одной ленте) и можно обойтись без джоинов для разной периодичности
Во всех платежных системах принцип один.
В своей базе фиксируете желание пользователя заплатить/оплатить заказ.
Отправляете на страницу оплаты с указанием за что конкретно платится.
Есть подвиды, когда нужно до этого дернуть апи платежной системы и зарегистрировать там , получив конкретную ссылку, уточняющий параметр.
От платежной системы приходят два вызова.
Перед началом списания денег, что вы готовы их принять(зафиксировать покупку). Обычно такой хук тупо отвечает. Да давай деньги быстрей.
Буквально через секунду летит второй вызов (я его авизкой называю)
Тебе пришли деньги. Столько то. И вот в этот вызов платежные системы дают обычно протянуть дополнительные поля. Полезную нагрузку от кого и за что оплата. Обычно уточняющим выступает номер заказа.
При приходе авизо делаются все проверки. Точно платежная система ? сумма правильная ? и т.п. Но если отправителя обязательно проверять,
то платеж можно просто зафиксировать и оставить человеку окончательную роль принятия решения, что с оплатой все хорошо.
Т.е. Если не сошлось в копейках из-за конвертации код может сам прощать или помечать заказ что оплата была в таком то размере.
А вот тому, что приходит с гет параметрами при редиректе пользователя я бы не верил.