Ilya
как минимум может можно вернуться к ОРМ с чистого скуэля?
Ilya
мне кажется, это должно реализоваться просто двумя транзакциями. но если сейвпоинты ок - то пусть будут
по сути первая транзакия триггер второй
Ilya
но рутина не пойдет - если накрылась большая транзакция то апдейты тоже должны уйти
Anonymous
в целом звучит как ок, просто savepoint заставляет как минимум иметь общий справочник уже сделанных сейвпоинтов, уметь генерировать им неповторяющиеся имена - вообщем все-таки как по мне, это достаточно сложно
Ilya
разве что через канал информировать рутину что едем назад...
Ilya
Ilya
и последовательное исполнение
Ilya
Anonymous
добрый день еще раз, я сформулирую точнее вот код на пастебин скинул https://pastebin.com/tbLVicLe
сделал как мне кажется подсчет количества вакансий очень костыльно, есть ли правильный путь? вопрос сформулировать по человечески не могу до сих пор, потому что только учу программирование.
Pawel
Squirrel
у меня уже есть много охрененть каких длинных запросов. Переписывать их в sql builder не вариант совсем. Хочется тупо вставить параметр в запрос.
Anonymous
добрый день еще раз, я сформулирую точнее вот код на пастебин скинул https://pastebin.com/tbLVicLe
сделал как мне кажется подсчет количества вакансий очень костыльно, есть ли правильный путь? вопрос сформулировать по человечески не могу до сих пор, потому что только учу программирование.
а именно вопрос в этой строке fmt.Printf("%v\n%v\n%v\n\n", vacancy.Items[i].Name, vacancy.Items[i].AlternateURL, vacancy.Items[i].Snippet.Requirement), в которой мне неизвестно количество данных в items[]
Aleksey
For range по items
Anonymous
Добрый день, есть тут кто-нибудь кто работал с graphql пакетом в го?
"errors":[{"message":"Field \"first_object\" of type \"Object\" must have a sub selection.
Бросает ошибку, но я не могу нагуглить проблему, и не очень хорошо ей в целом понимаю
Artem
Anonymous
в запросе?
Artem
да
Anonymous
Окей, спасибо, понял
Anonymous
Добрый день, есть тут кто-нибудь кто работал с graphql пакетом в го?
"errors":[{"message":"Field \"first_object\" of type \"Object\" must have a sub selection.
Бросает ошибку, но я не могу нагуглить проблему, и не очень хорошо ей в целом понимаю
На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.
Anonymous
Anonymous
На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.
К тому же у меня совсем маленький проект для личного использования так что думаю я не столкнусь с этой проблемой
qurabay
Не хватает время на то чтобы инвестировать мозг помогитееееее
Pavel
Не хватает время на то чтобы инвестировать мозг помогитееееее
это прелюдия для рекламы закрытого канала за 1 биток?
Aleksandr
На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.
можно любой сервер нагружать у которого апи торчит
Anonymous
можно любой сервер нагружать у которого апи торчит
Думаю он имел в виду что можно более эффективно нагружать графкл сервер
Aleksandr
Думаю он имел в виду что можно более эффективно нагружать графкл сервер
он наверняка в комментах читал, что это не проблема graphql
Artem
Думаю он имел в виду что можно более эффективно нагружать графкл сервер
про какие нагрузки вообще речь?
Anonymous
Думаю, миникопию срача с хабра сюда не стоит переносить, главное, учитывать особенность graphql в этом плане.
Artem
У нас был графкуэль, он удобен для фронтов. Но там надо следить за гидрированием его моделей. Там всплывает нюанс, что он может доставать данные ненужные для запроса. Либо доставать их повторно. К примеру для 100 книг 100 раз тянуть одного автора.
Artem
А наши хаки упирались в умение фронтов новые виды запросов посылать проходящие мимо преанализа
Roman
На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.
если graphql сервер реализован наивно и resolver'ы ходят в бд тогда естественно.
GraphQL это мощный инструмент, а с большой силой как известно приходит и большая ответственность. Нужно понимать как работает граф resolver.
Batching и кэширование вам в помощь, тогда я бы даже поспорил что будет держать нагрузку лучше, ручками написанный отлаженный REST или с умом написанный GraphQL
Alexey
https://www.youtube.com/watch?v=HXqrsU7y0lU
.
В этом примере:
if res, err := r(); err != nil {
fmt.Println(res)
}
У нас переменные созданные тут сразу же удалятся со стека?
Alexey
Вопрос по правилам языка или по реализации?
Sergey
Alexey
Зависит от типа res, что там внутри
Alexey
Можно запустить компилятор с каким-то флажком и посмотреть на вывод escape analysis
.
Ну как я понимаю err сразу же убирается?
.
Мне просто стал интересен вопрос оптимизации когда у нас в функции происходит много проверок на ошибки. Есть два варианта
первый
if _, err := strconv.Atoi("100"); err != nil {
return err
}
if _, err := strconv.Atoi("100"); err != nil {
return err
}
...
и второй, где переменная err у нас используется несколько раз
_, err := strconv.Atoi("100")
if err != nil {
return err
}
_, err = strconv.Atoi("100")
if err != nil {
return err
}
...
.
И второй вариант оказался быстрее в пределах 10 наносекунд
.
Так что так себе оптимизация в ущерб читабельности 😂
Roman
Ребят, я немного помозговал по теме const reference types (указатели, слайсы, мапы) и таки пришёл к выводу, что указатель и объект на который он указывает это таки 2 разные сущности, поэтому в идеале:
- указатель на иммутабельный объект нужно указывать так:
* const Object
- иммутабельный указатель на иммутабельный объект вот так:
const * const Object
- а иммутабельный указатель на мутабельный объект так:
const * Object
Aleksandr
выглядит логично
Dorian
Один уровень вложенности, прекрасно
.
Ну да
Roman
Ребят, я немного помозговал по теме const reference types (указатели, слайсы, мапы) и таки пришёл к выводу, что указатель и объект на который он указывает это таки 2 разные сущности, поэтому в идеале:
- указатель на иммутабельный объект нужно указывать так:
* const Object
- иммутабельный указатель на иммутабельный объект вот так:
const * const Object
- а иммутабельный указатель на мутабельный объект так:
const * Object
однако были предложения наследовать иммутабельность объекта от reference типа по умолчанию, т.е. проще говоря упростить const * const Object до const *Object теряя при этом возможность декларации мутабельных указателеи на иммутабельные объекты.
в таком случае const *Object это НЕ-мутабельный указатель на НЕ-мутабельный объект, а const []*Object это НЕ-мутабельный слайс НЕ-мутабельных указателей на НЕ-мутабельные объекты
И я пока-что не уверен, стоит ли это делать?
ведь в таком случае практически невозможно задекларировать мутабельный слайс немутабельных объектов, например.
но читать const [] const * const Object как-то тоже не очень, хоть и логично.
Dorian
Чувства двоякие, но хочется плюнуть на логику и сделать лаконично, т.е. упрощенный вариант, дающий только немутабельную связку
Roman
Чувства двоякие, но хочется плюнуть на логику и сделать лаконично, т.е. упрощенный вариант, дающий только немутабельную связку
аналогично, но при этом, повторюсь, теряем возможность декларации мутабельных reference typo'ов (типа slice, map, pointer) на немутабельные объекты
Pavel
а что если сделать все немутабельным, пока ключевое слово (типа `volatile`) не пропишешь?!
Pavel
и канал если не мутабельный, то сообщения посылать нельзя, только закрывать 🙂
Roman
а что если сделать все немутабельным, пока ключевое слово (типа `volatile`) не пропишешь?!
уже обсуждалось и с сегодняшнего дня описано в введении: https://github.com/romshark/Go-2-Proposal---Immutability#1-introduction
Ideally a programming language should enforce immutability by default while the developers must explicitly annotate mutable symbols as such, but this concept would require significant, backwards-incompatible languages changes breaking existing Go 1.x code. To prevent breaking Go 1.x compatibility this document describe an approach to immutability by overloading the const keyword (see here for more details) to act as an immutable type qualifier similar to languages like C++.
Pavel
ну для го 2.0 почему б идеально не сделать
Dorian
Говорят он вторйо только с маркетинговой точки зрения и оставят обратную совместимость
Dorian
В этом же чате и говорят, впринципе
Bogdan (SirEdvin)
Очень боятся повторить судьбу питона, да
Roman
ну для го 2.0 почему б идеально не сделать
я говорю в данном пропосале не только про Go 2, но и возможную backwards-compatible реализацию в Go 1.x
Bogdan (SirEdvin)
Хотя у него все хорошо уже. Почти)
Pavel
ну всем хорошо не сделать
Dorian
Нормальная судьба у Питона. Просто не всем знакома система версий
Dorian
Это из разряда, когда люди думают что после 1.9 идет 2.0
Roman
однако были предложения наследовать иммутабельность объекта от reference типа по умолчанию, т.е. проще говоря упростить const * const Object до const *Object теряя при этом возможность декларации мутабельных указателеи на иммутабельные объекты.
в таком случае const *Object это НЕ-мутабельный указатель на НЕ-мутабельный объект, а const []*Object это НЕ-мутабельный слайс НЕ-мутабельных указателей на НЕ-мутабельные объекты
И я пока-что не уверен, стоит ли это делать?
ведь в таком случае практически невозможно задекларировать мутабельный слайс немутабельных объектов, например.
но читать const [] const * const Object как-то тоже не очень, хоть и логично.
поэтому ради общего блага я пока-что решил использовать менее ограничивающий, но более громоздкий вариант, когда указатель или slice отдельно от объекта анотируется на (и)мутабельность
worst case:
const map[const * const Object] const * const Object
иммутабельный мап, с иммутабельным указателем на иммутабельный объект в качестве ключа на иммутабельный указатель на иммутабельный объект
если кому-то данная тема интересна то буду рад обсудить аргументы за упрощённый, но ограничивающий вариант
Bogdan (SirEdvin)
Нормальная судьба у Питона. Просто не всем знакома система версий
Ну, еще лет 5 назад был совсем ад, когда практически все либы или поддерживали 2.7 или были только на 2.7.
Просто стоит учитывать. что миграция на мажорку стоит денег и очень часто ее откладывают на тогда, когда уже нельзя терпеть.
Daniel
коллеги
Dorian
Мы познаем в сравнении
Daniel
go не грозит судьба питона никаким образом
Pavel
гугл просто наймет больше рабов и все мигрирует 🙂
Dorian
В го менять то нечего, чтобы сломать
Bogdan (SirEdvin)
go не грозит судьба питона никаким образом
Даже если сделать несовместимые изменения в, скажем, go 2?
В go уже такая ситуация с модулями, которые вроде как в стандарте, а у кучи либ как была версионность по коммитам, так и остается :)
Или вы про другую судьбу питона?
Roman
гугл просто наймет больше рабов и все мигрирует 🙂
стд. библиотеку то может они и подправят, а вот community packages могут затянуться, некоторые возможно даже не перейдут на Go 2 вообще (из-за вялой поддержки пакета например)
вся сложность иммено в стороннем коде, который сломают
Daniel
я про то, что никто не мешает вам продолжать компилять свои поделия go1
Daniel
это питону требовалось следить за тем, что там у пользователя установлено
Daniel
а мы-то бинарники распространяем
Bogdan (SirEdvin)
Это же и называется "судьба питона", когда одновременно будут две редакции одного языка.
Roman
я про то, что никто не мешает вам продолжать компилять свои поделия go1
невозможно будет скомпилить свой проект в Go2 с зависимостью из Go1
Sergey
В языке где регистр первой буквы определяет видимость, а ошибки это просто строки херня вида const * const не пройдёт