NK
был готов даже крокодил по вене гонять, лишь бы не видеть эту дичь больше
У меня примерно такое же состояние было при работе с одним проектом))
Size: a a a
2020 July 23
S
У меня примерно такое же состояние было при работе с одним проектом))
КА
Сейчас где-то Alex истерически засмеялся ахах
FF
Сейчас где-то Alex истерически засмеялся ахах
У меня после быстрого знакомства с yii2 так себе ощущения однозначно он сыроват много писать я хоть и могу писать, но зачем мне изобретать, то что уже есть и да получил-таки добро быстро перенести все на нормальную систему благо проект только в стадии mvp.
Я рад этому)
Я рад этому)
S
Ребят, такой вопрос: на сайте должна быть оплата по нескольким типам платежных систем, банковского перевода и наличными. Естественно для каждой платежной системы есть свое апи. И отдельная модель транзакции. Как связать транзакции с заказами чтобы у заказа отображалась транзакция той платежной системы которая была выбрана при создании заказа?
FF
Ребят, такой вопрос: на сайте должна быть оплата по нескольким типам платежных систем, банковского перевода и наличными. Естественно для каждой платежной системы есть свое апи. И отдельная модель транзакции. Как связать транзакции с заказами чтобы у заказа отображалась транзакция той платежной системы которая была выбрана при создании заказа?
Сделай поле t_type у заказа
S
Fares Fares
Сделай поле t_type у заказа
И t_id?
FF
Ну вообще отдельную сущность платежи и прязка к заказу
S
просто payment type туда пиши и все
S
просто payment type туда пиши и все
JSON сохранять?
FF
JSON сохранять?
Я бы сделал в сущности платеж сохранение в поле json ответ от getway
v
Разделить:
Таблица payments - сохранение платежек, сохранение со внешним идентификатором платежки во внешней системе + типом/способом оплаты
Таблица payment_transactions - Сохранение колбэков от внешних систем, с транзакциями по платежу.
тип системы какой-нибудь enum если не частое изменение либо char(3) и 3 символные фиксированные значения.
Таблица payments - сохранение платежек, сохранение со внешним идентификатором платежки во внешней системе + типом/способом оплаты
Таблица payment_transactions - Сохранение колбэков от внешних систем, с транзакциями по платежу.
тип системы какой-нибудь enum если не частое изменение либо char(3) и 3 символные фиксированные значения.
S
Fares Fares
Я бы сделал в сущности платеж сохранение в поле json ответ от getway
Можешь уточнить что имеешь ввиду под сущностью?
S
Разделить:
Таблица payments - сохранение платежек, сохранение со внешним идентификатором платежки во внешней системе + типом/способом оплаты
Таблица payment_transactions - Сохранение колбэков от внешних систем, с транзакциями по платежу.
тип системы какой-нибудь enum если не частое изменение либо char(3) и 3 символные фиксированные значения.
Таблица payments - сохранение платежек, сохранение со внешним идентификатором платежки во внешней системе + типом/способом оплаты
Таблица payment_transactions - Сохранение колбэков от внешних систем, с транзакциями по платежу.
тип системы какой-нибудь enum если не частое изменение либо char(3) и 3 символные фиксированные значения.
У всех типов оплат разные транзакции я столкнулся с тем что у меня не хватали некоторые поля, а для другой платёжки эти поля были лишними, решил проблему добавив jsonable поле. А теперь не могу написать нормальные фильтры по этому полю
v
У всех типов оплат разные транзакции я столкнулся с тем что у меня не хватали некоторые поля, а для другой платёжки эти поля были лишними, решил проблему добавив jsonable поле. А теперь не могу написать нормальные фильтры по этому полю
Таблицу создаешь стандартно выделяя одинаковые столбцы во всех типах платежек, а ответы кладешь в raw json столбец, как получил из внешней системы.
В случае если понадобятся новые столбцы, можно их создать и собрать из raw объектов сохраненных ранее.
Сами столбцы лучше создавать по планируемым фильтрам или выборкам.
В случае если понадобятся новые столбцы, можно их создать и собрать из raw объектов сохраненных ранее.
Сами столбцы лучше создавать по планируемым фильтрам или выборкам.
v
тоесть у тебя есть столбцы которые участвуют в фильтрах и выборках.. Сумма, Способ, Идентификатор из внешней системы, номер карты, данные срока карты и т д.
И для каких-то не стандартных моментов есть raw объект, который можно использовать как для заполнения новых столбцов путем миграции, либо вывода где-то в верстке, либо дополнительной фильтрации какой-то
И для каких-то не стандартных моментов есть raw объект, который можно использовать как для заполнения новых столбцов путем миграции, либо вывода где-то в верстке, либо дополнительной фильтрации какой-то
S
Я примерно так же сделал. То есть сохранял все данные от транзакции в jsonable. А остальные по своему желанию доработал. Хочешь сказать что это норм?
v
Я примерно так же сделал. То есть сохранял все данные от транзакции в jsonable. А остальные по своему желанию доработал. Хочешь сказать что это норм?
Данные в jsonable скорее нужны чтобы иметь тело оригинального объекта.
Это нормально.
А вот фильтры и общие данные которые необходимы для работы системы, например:
1. Внешний иденитифкатор транзакции
2. Сумма транзакции
3. Способ оплаты
4. Номер карты (либо связь с реестром карт)
5. Реккурентный токен
лучше сделать отдельными от jsonable столбцами
Это нормально.
А вот фильтры и общие данные которые необходимы для работы системы, например:
1. Внешний иденитифкатор транзакции
2. Сумма транзакции
3. Способ оплаты
4. Номер карты (либо связь с реестром карт)
5. Реккурентный токен
лучше сделать отдельными от jsonable столбцами
v
ну тоесть, я вижу данные от внешней системы сохраненные в jsonable столбце, только как необходимость иметь оригинальный объект.
Часто бывает, необходимо расширить таблицу, например добавить столбец срока действия карты с которой платили, или добавить каким реккурентным токеном пользовались.
Тогда миграцией создаются новые столбцы, и заполняются из raw объекта при миграции.
Часто бывает, необходимо расширить таблицу, например добавить столбец срока действия карты с которой платили, или добавить каким реккурентным токеном пользовались.
Тогда миграцией создаются новые столбцы, и заполняются из raw объекта при миграции.
S
ну тоесть, я вижу данные от внешней системы сохраненные в jsonable столбце, только как необходимость иметь оригинальный объект.
Часто бывает, необходимо расширить таблицу, например добавить столбец срока действия карты с которой платили, или добавить каким реккурентным токеном пользовались.
Тогда миграцией создаются новые столбцы, и заполняются из raw объекта при миграции.
Часто бывает, необходимо расширить таблицу, например добавить столбец срока действия карты с которой платили, или добавить каким реккурентным токеном пользовались.
Тогда миграцией создаются новые столбцы, и заполняются из raw объекта при миграции.
+ хорошо, на мой взгляд тоже норм, но не очень хочется доверять к jsonable поэтому задал вопрос, спасибо)