а если платить, то быстро ;)

но деньги переводяться по факту продавцу - также через время

давай проверим, я тебе скину карту ))

да, но блокировка средств происходит мгновенно

скидывайте карту, фио, до когда карта и 3 циферки с обратной стороны

зачем все усложнять, я тебе ремут доступ дам ))

Привет, ребят.
Подскажите пожалуйста, почему у меня в такой интерпретации при миграции внешний ключ формируется как уникальный?
Я бы не хотел уникальности внешних ключей.. Как можно это обратить?
...

#[ORM\OneToOne(targetEntity: Country::class)]
#[ORM\JoinColumn(name: "country_id")]
private Country $country,

...
=>

$this->addSql('CREATE UNIQUE INDEX UNIQ_F64E86D6F92F3E70 ON shop_recipient_addresses (country_id)');

acid не особо нужен может?)

а как по-другому гарантировать точность баланса ?

ну то есть тебе ж консистентность по итогу нужна, какая разница как именно консистентность достигается

потому что связь OneToOne, либо используй OneToMany
я вообще при связи OneToOne в качестве первичного ключа в дочерней сущности использую именно id родителя

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

но даже если допустить что реалистично - надо уже смотреть на то какие транзакции и т.д. и какие доп требования мы выставляем системе. Скорее всего "всегда консистентно" уже не вариант и надо смотреть что можно с этим делать

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

А как называется в доктрине альтернативная связь BelongsTo ларавеля?

ну то есть универсальный вариант для такого узкого кейса не подберешь, надо всегда смотреть на общую картину. Можно просто поговорить с бизнесом и ввести овердрафт)

Ээээээм, что эта

скриншет вместо реплая

Я про артефакты в тексте