EA
От местных работодателей, не российских удалённо.
Size: a a a
2019 January 16
U
а, да, есть
U
ну хотя за всех не отвечу, я пару раз встречал
EA
На Лурке писали страшное, что кодер в РБ 1000 имеет. Статья старая и я не поверил, все бы у соседей были.
OG
я еще страшнее скажу разраброс зп огромен, и ниже бывает )
OG
все зависит от того кто с кем работает
EA
Стандартный юниор в Москве 48 000. По часовой ставке можно и менее.
OG
за пределами москвы тоже жизнь есть, но честно говоря считаю что обсуждения зп это не совсем уместно в рамках этого канала
2019 January 17
P@
1) Осталось одно поле, avatar переименовалось в photo
2) Если данные уже есть в бд (т.е. нарушается констрейнт) - то только через флаг
3.1, 3.2) Коротко: так лучше не делать, будет работать через раз, например если создать поле с другим типом - напишет что всё ок (на самом деле тип в бд останется старый), если после этого поменять тип на другой (через призму) - напишет что всё ок, а если после этого опять через призму поменять обратно на другой тип - ругнётся. Лучше в обход призмы в бд не лезть создавать что-нибудь, такие таблицы лучше создавать в отдельной
2) Если данные уже есть в бд (т.е. нарушается констрейнт) - то только через флаг
--force, который удалит весь столбец, а если столбец пустой - то просто пересоздаст его (удалит и создаст новый, с новым типом) Changes:
User (Type)
~ Updated field `string_int`
3.1, 3.2) Коротко: так лучше не делать, будет работать через раз, например если создать поле с другим типом - напишет что всё ок (на самом деле тип в бд останется старый), если после этого поменять тип на другой (через призму) - напишет что всё ок, а если после этого опять через призму поменять обратно на другой тип - ругнётся. Лучше в обход призмы в бд не лезть создавать что-нибудь, такие таблицы лучше создавать в отдельной
schema в бд. Но если очень нужно - то в призме есть интроспекция бд в схему (т.е. в призму импортируется схема существующей бд)Спасибо за ответы. Утащил в репку.
a
Павел, вчера читал ваши рекомендации по проектированию схемы
a
Вы советуете группировать мутации в неймспейсы
a
Видел в интернете статью где говорится что при такой организации не гарантируется последовательное выполнение мутаций
a
Насколько я понимаю речь о двух мутациях из одного неймспейса пришедших одновременно на сервер
a
возможно стоит упомянуть об этом в документе
В🌎
Так это ведь про параллельные мутации, а не про организацию в неймспейсы
a
насколько я понимаю, некоторые на фронте сейчас делают так
a
mutation {
doStuff1() {
id
}
doStuff2() {
id
},
}a
при таком запросе graphql сервер выполнит их последовательно и это гарантируется спецификацией
a
но если поместить эти две мутации в "неймспейс":