безотносительно сути вопроса: а почему нуллабельное-то?

потому что его не существует, пока в базу не попадёт

безотносительно сути вопроса: а почему нуллабельное-то?

Пока не зафлешили у сущности нету ида (автогенерация же средствами бд)

не, я понимаю. и?

Сделать setId или добавить флаг игнорирования ошибки

и как его добавить? перекопал контекстное меню, там чот нифига нету

не, я понимаю. и?

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

не, я понимаю. и?

вот так оно всё равно стрельнет, если у незафлашенной сущности getId позвать - потому что поле нуллом не проинициализировано. то есть ошибка один хер останется, если позвать getId до сохранения

а вот что нуллабельный геттер наружу торчит - это точно идиотизм, ведь теперь нулл-чекер везде будет орать что getId может нулл вернуть

и везде придется либо suppress-ить этот ворнинг, либо писать постоянные дебильные проверки на нулл

и как его добавить? перекопал контекстное меню, там чот нифига нету

в конструкторе добавь $this->id = null;

в конструкторе добавь $this->id = null;

зачем, если можно сразу написать private ?int $id = null; нахера в конструкторе-то?

зачем, если можно сразу написать private ?int $id = null; нахера в конструкторе-то?

а зачем в проперти?)

и как его добавить? перекопал контекстное меню, там чот нифига нету

Какой-то из этих должен подойти: https://gist.github.com/discordier/ed4b9cba14652e7212f5?permalink_comment_id=2819739#gistcomment-2819739 Можно еще отключить эту проверку и не костылить

Сэкономить строчку в конструкторе? )

зачем, если можно сразу написать private ?int $id = null; нахера в конструкторе-то?

собсна, всё что не ставится в конструкторе, должно проставляться в свойствах

а потом добавится спецификатор readonly твой сет в проперти не будет работать)

readonly в рантайме не нужен readonly нужен при статанализе и надо просто не использовать магию

зачем, если можно сразу написать private ?int $id = null; нахера в конструкторе-то?

собсна, почему всратый пхп дефолтом не проставляет значения, если стоит ? в типе поля?

собсна, почему всратый пхп дефолтом не проставляет значения, если стоит ? в типе поля?

а почему он должен?

readonly в рантайме не нужен readonly нужен при статанализе и надо просто не использовать магию

не хочу пхпдоку) тут уже выбор каждого

а почему он должен?

чтобы экономить время программиста на чтение и проставление дефолтных нуллов

а почему он должен?

это работает когда типов нету) вроде

не хочу пхпдоку) тут уже выбор каждого

это вопрос дополнительных проверок потом каждое поле проверяется, а не ридонли ли оно

readonly в рантайме не нужен readonly нужен при статанализе и надо просто не использовать магию

шторм кстати пиздит, если реадонли не выставлен

я ща про инъекции всякие

это вопрос дополнительных проверок потом каждое поле проверяется, а не ридонли ли оно

не сильно экономишь по факту) не критично

и кстати, доктрине на реадонли кладет, постестил уже

можно смело юзать для всяких крейтед_ат и идов

ну только есть один нюанс с проксями)

собсна, почему всратый пхп дефолтом не проставляет значения, если стоит ? в типе поля?

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

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

ну так не указывайте типы и будет по дефолту нулл)

и кстати, доктрине на реадонли кладет, постестил уже

в доктрину, кстати, классные штуки для таких полей завезли:

insertable: false, updatable: false, generated: 'INSERT',

Тут все правильно

В чем вопрос

typed property сильно отличается от обычных

нет смысла сравнивать реализацию (или использовать untyped)

<?php class X { private ?int $foo; } var_dump(new X); //// object(X)#1 (0) { ["foo":"X":private]=> uninitialized(?int) }

видишь, тут появился специальный флаг "инициализировано"

и кстати, доктрине на реадонли кладет, постестил уже

так и должно быть десериализация - это не операция редактирования или создания

Приветствую. Вопрос symfony uuid компоненту, он генерирует binary поле в БД. В принципе вроде как лучше по сравнению с varchar. Но как более менее адекватно приводить к стрингу на чтении? BIN_TO_UUID - ну не очень каждый раз такое писать в raw sql

много записей в этой таблице ожидается?

много записей в этой таблице ожидается?

Некоторых много, некоторых не очень. Uuid везде

define много - десятки миллионов?

define много - десятки миллионов?

Ну такого наверно не будет

А как влияет на задачу?

просто если нет, я бы посоветовал не заниматься микрооптимизациями, а юзать варчар и не париться

вот это как хранит, не смотрели? https://symfony.com/blog/new-in-symfony-5-2-doctrine-types-for-uuid-and-ulid

просто если нет, я бы посоветовал не заниматься микрооптимизациями, а юзать варчар и не париться

Да так это не микро, просто по дефолту заюзал uuid сифмони

энивей нужен кастомный тип доктрины

либо свой, либо встроенный. а он уже за собой скроет детали реализации, типа упаковку/распаковку

и что именно при чтении надо конвертировать? чтобы в sql операции над строками проводить?

видимо чтобы туда-сюда касты не писать. но для этого кастом тайп и нужен

и что именно при чтении надо конвертировать? чтобы в sql операции над строками проводить?

Просто вывести json, падает из-за бинаря)

Просто вывести json, падает из-за бинаря)

а как щас описано поле?

а как щас описано поле?

binary 16. Так кастит диф миграции

в доктрине в смысле, в сущности

а каким образом оно в json попадает?

в доктрине в смысле, в сущности

uuid

а каким образом оно в json попадает?

Из базы

просто обычный select запрос через connection, он возвращает binary, ну и падет потом responseJson

где то в глубине)

а, тут ничего не поделать, в ручных запросах надо каст писать руками

как за вас pdo должно догадаться, что вот конкретно это бинарное поле вы хотите видеть в каком-то текстовом представлении?

Херобора на пустом месте :(

так я и говорю, используйте варчар, пока это не станет проблемой, потом поменяете

как за вас pdo должно догадаться, что вот конкретно это бинарное поле вы хотите видеть в каком-то текстовом представлении?

Да я понимаю, сделали бы хотя бы чтоли настройку) Походу так и придется хаводить свой тип

так я и говорю, используйте варчар, пока это не станет проблемой, потом поменяете

Надо свой тип или рамси завозить

не поможет свой тип, когда вы пишете raw sql (я же правильно понял?) доктрина не участвует в процессе вообще

не поможет свой тип, когда вы пишете raw sql (я же правильно понял?) доктрина не участвует в процессе вообще

На другом проекте Ramsy uuid он генерит varchar 32, это все прописывается в настройках типа доктрины же

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

рамси просто генерит строчку, обернутую в VO, он ничего не знает ни про базы, ни про доктрины, ни про что вообще

возьмите вон по ссылке выше способ описания через кастом ид генератор

рамси просто генерит строчку, обернутую в VO, он ничего не знает ни про базы, ни про доктрины, ни про что вообще

Там есть свой тип для доктрины в либе

guid вроде "спасает" (upd нет :( )

теперь еще раз: "обычный select запрос через connection" - речь про native sql query отсюда? https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/native-sql.html

не через DQL/QueryBuilder?

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