MP
обновление базы через миграции или c synchronize: true ?
Size: a a a
2020 September 15
SL
у меня синхронайз отключен
SL
иначе он каждый раз пытался создать новую таблицу
SL
или что-то такое было
MP
а как миграция выглядит для этого поля?
SL
я этого не делал
MP
тебе проще написать миграцию для твоей таблицы в которой будет что то в духе
MP
у меня таким образом все генерится
SL
SL
спасибо, пойду разбираться
I
Привет! Подскажите, кто как делает, если по-феншую. CRUD
create - возвращаем id/data
update - 204/id/data
view - data
есть ли смысл после обновления сущности возвращать все поля? или только 204 например а потом уже по нужному id вернем нужные данные
create - возвращаем id/data
update - 204/id/data
view - data
есть ли смысл после обновления сущности возвращать все поля? или только 204 например а потом уже по нужному id вернем нужные данные
PP
Все зависит от требований. Но по опыту разработки фронта, скажу что удобно, когда все ресты возвращают данные. В общем то для разработке бека разницы нет обычно, поэтому в целом, мое мнение, что лучше возвращать.
DD
как это работает?
I
Все зависит от требований. Но по опыту разработки фронта, скажу что удобно, когда все ресты возвращают данные. В общем то для разработке бека разницы нет обычно, поэтому в целом, мое мнение, что лучше возвращать.
вот и думаю. всегда по разному делал, хочу к одной структуре придти.
По логике реста и четкой архитектуры, нужны данные юзера, сделай users/1 (GET)
но с другой стороны, это два запроса, один на изменение, другой на получение
По логике реста и четкой архитектуры, нужны данные юзера, сделай users/1 (GET)
но с другой стороны, это два запроса, один на изменение, другой на получение
PP
вот и думаю. всегда по разному делал, хочу к одной структуре придти.
По логике реста и четкой архитектуры, нужны данные юзера, сделай users/1 (GET)
но с другой стороны, это два запроса, один на изменение, другой на получение
По логике реста и четкой архитектуры, нужны данные юзера, сделай users/1 (GET)
но с другой стороны, это два запроса, один на изменение, другой на получение
Согласен, но всегда возвращать, реально удобнее.
Как пример того как делают умные люди могу привести qraphQL там при изменении данных вы также передаете квери для получения ответа.
Можете смотреть на это как на оптимизацию. Очень часто вам аосле создания сущности надо получить актуальные данные. Поэтому проще их всегда возвращать
Как пример того как делают умные люди могу привести qraphQL там при изменении данных вы также передаете квери для получения ответа.
Можете смотреть на это как на оптимизацию. Очень часто вам аосле создания сущности надо получить актуальные данные. Поэтому проще их всегда возвращать
DD
Ребят,как у меня это работает,я вроле бы не передаю рефлектор в конструктор
DD