я подозреваю у него нет никаких констрейнтов на уникальность, так что пользователь так и будет создаваться и ошибки никакой не будет чего он как раз хочет избежать
Ипатьев, типизация в вашем случае строже не получается, просто вы неявно сделали эдакий NullObject. Типизация нам говорит о том, чего ожидать от обьявленного типа. В данном случае получается что-то типа Optional, т.е. обьекта может не быть и мы явно указали чего ожидать. Как потом проверять, это действительно юзер, или фейк обьект? Всё таки ?UserObject проще и правильней будет. Если я запрашиваю юзера по id=1 допустим, и мне возвращается нул, то я явно понимаю и обрабатываю кейс если такого юзера нет. В вашем случае я не понимаю как обрабатывать тот же самый кейс.
Господи прекрати распространять легенду что новичков не берут на удаленку) Берут. Не знаю на сколько часто, не мерял, но берут. У меня на работе полностью распределенная команда, в ней как минимум два джуна на фронте и один начинающий админ, и все трое удаленно работают.
AUser0, не буду говорить, что понимаю как это работает на уровне ядра, но разве не приложение создает соединение в т.ч. создавая сокет? Почему оно неизвестно на момент TCP hanshake? И что значит "выбран"?
nowm, тогда странно, обычно это должно работать и процесс должен показываться. Я не эксперт в этом, но где-то читал, что руткиты могут скрывать процессы. Возможно стоит посмотреть в эту сторону.
Отсутствующий процесс может означать, что недостаточно прав для просмотра, что это за процесс. Если под судо запустить нетстат, то вполне вероятно процесс станет известен.
Обычно под сервисом имеют ввиду сервисный слой. Т.е. некий класс который реализует бизнес логику. ООП здесь никаким уже не пахнет, но это то дерьмо к которому пришли разработчики спустя столько лет :)
Мартин эти сервисы например называет UseCase
Sergey Myasoedov, распределенные транзакции они на то и распределенные, что выполняются не в рамках инстанса (физического) одной базы данных. По этой причине одна база данных не может гарантировать такие транзакции. Почитайте на эту тему "Designing Data Intensive Applications", главу про согласованность и консенсус. Так же полезно на эту тему узнать что такое паттерн Saga
tcccccc, Vladimir Onokhov, эти советы будут актуальны долгое время. Единственное что хотелось бы поправить - не UML а ERD диаграммы для БД нужно изучать + crow foot notation
Noder SS, что долго вы разбирались с этой темой) Найдите другой учебник, или если разбираетесь не по учебнику, то начните по учебнику. Вот еще на тему внешних ключей
По факту то что по ссылке описано и является причиной необходимости FK.
Это не всегда и не обязательно так. Тут дело в том, что стек это непрерывная область памяти к которой имеет доступ весь процесс. Когда создается новая функция, то стек растет и можно обратиться к этой вновь выделенной памяти, т.е. ваша горутина имеет доступ к той памяти которая выделена под стековый фрейм main функции. Но это очевидно не работает в обратную сторону, из main в свою анонимную горутину вы не обратитесь, потому что на момент выполнения main память под ту горутину еще не выделена.
Slava Rozhnev, да, my bad, всегда указываю действие при update и delete и уже забыл, что если они не указаны, то база просто не даст удалить, выдав ошибку.