но если обновление таблиц не удастся - то и фиг с ними, крон потом подберет, а вот основная транзакция это basic values

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

не, если есть другие решения - давайте, может они эффективнее

как минимум может можно вернуться к ОРМ с чистого скуэля?

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

по сути первая транзакия триггер второй

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

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

разве что через канал информировать рутину что едем назад...

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

ну тут к счастью один пойнт

и последовательное исполнение

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

пойнт же локален в передлах транзакции

пойнт же локален в передлах транзакции

да

добрый день еще раз, я сформулирую точнее вот код на пастебин скинул https://pastebin.com/tbLVicLe сделал как мне кажется подсчет количества вакансий очень костыльно, есть ли правильный путь? вопрос сформулировать по человечески не могу до сих пор, потому что только учу программирование.

Squirrel

у меня уже есть много охрененть каких длинных запросов. Переписывать их в sql builder не вариант совсем. Хочется тупо вставить параметр в запрос.

добрый день еще раз, я сформулирую точнее вот код на пастебин скинул 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[]

For range по items

For range по items

спасибо большое

Добрый день, есть тут кто-нибудь кто работал с graphql пакетом в го? "errors":[{"message":"Field \"first_object\" of type \"Object\" must have a sub selection. Бросает ошибку, но я не могу нагуглить проблему, и не очень хорошо ей в целом понимаю

Добрый день, есть тут кто-нибудь кто работал с graphql пакетом в го? "errors":[{"message":"Field \"first_object\" of type \"Object\" must have a sub selection. Бросает ошибку, но я не могу нагуглить проблему, и не очень хорошо ей в целом понимаю

нужно выбрать поля у объекта

в запросе?

да

Окей, спасибо, понял

Добрый день, есть тут кто-нибудь кто работал с graphql пакетом в го? "errors":[{"message":"Field \"first_object\" of type \"Object\" must have a sub selection. Бросает ошибку, но я не могу нагуглить проблему, и не очень хорошо ей в целом понимаю

На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.

На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.

Спасибо за информацию, учту

На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.

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

Не хватает время на то чтобы инвестировать мозг помогитееееее

Не хватает время на то чтобы инвестировать мозг помогитееееее

это прелюдия для рекламы закрытого канала за 1 биток?

Спасибо за информацию, учту

Предупреждён - вооружен ))

На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.

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

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

Думаю он имел в виду что можно более эффективно нагружать графкл сервер

Думаю он имел в виду что можно более эффективно нагружать графкл сервер

он наверняка в комментах читал, что это не проблема graphql

Думаю он имел в виду что можно более эффективно нагружать графкл сервер

про какие нагрузки вообще речь?

Думаю, миникопию срача с хабра сюда не стоит переносить, главное, учитывать особенность graphql в этом плане.

У нас был графкуэль, он удобен для фронтов. Но там надо следить за гидрированием его моделей. Там всплывает нюанс, что он может доставать данные ненужные для запроса. Либо доставать их повторно. К примеру для 100 книг 100 раз тянуть одного автора.

А наши хаки упирались в умение фронтов новые виды запросов посылать проходящие мимо преанализа

На хабре как-то статья была и там graphql не хвалили - т.е. с его помощью можно специально нагружать (создавать нагрузку) серверы, у которых оный наружу торчит.

если graphql сервер реализован наивно и resolver'ы ходят в бд тогда естественно. GraphQL это мощный инструмент, а с большой силой как известно приходит и большая ответственность. Нужно понимать как работает граф resolver. Batching и кэширование вам в помощь, тогда я бы даже поспорил что будет держать нагрузку лучше, ручками написанный отлаженный REST или с умом написанный GraphQL

https://www.youtube.com/watch?v=HXqrsU7y0lU

В этом примере: if res, err := r(); err != nil { fmt.Println(res) } У нас переменные созданные тут сразу же удалятся со стека?

Вопрос по правилам языка или по реализации?

Вопрос по правилам языка или по реализации?

Реализации я думаю

Зависит от типа res, что там внутри

Можно запустить компилятор с каким-то флажком и посмотреть на вывод 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 наносекунд

Так что так себе оптимизация в ущерб читабельности ?

Ребят, я немного помозговал по теме const reference types (указатели, слайсы, мапы) и таки пришёл к выводу, что указатель и объект на который он указывает это таки 2 разные сущности, поэтому в идеале: - указатель на иммутабельный объект нужно указывать так: * const Object - иммутабельный указатель на иммутабельный объект вот так: const * const Object - а иммутабельный указатель на мутабельный объект так: const * Object

выглядит логично

Так что так себе оптимизация в ущерб читабельности ?

А чо там нечитабельного?

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

А чо там нечитабельного?

ну, первый вариант мне нравится больше

ну, первый вариант мне нравится больше

А ну вкусовщина

Ну да

Ребят, я немного помозговал по теме 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 как-то тоже не очень, хоть и логично.

Чувства двоякие, но хочется плюнуть на логику и сделать лаконично, т.е. упрощенный вариант, дающий только немутабельную связку

Чувства двоякие, но хочется плюнуть на логику и сделать лаконично, т.е. упрощенный вариант, дающий только немутабельную связку

аналогично, но при этом, повторюсь, теряем возможность декларации мутабельных reference typo'ов (типа slice, map, pointer) на немутабельные объекты

а что если сделать все немутабельным, пока ключевое слово (типа `volatile`) не пропишешь?!

и канал если не мутабельный, то сообщения посылать нельзя, только закрывать ?

а что если сделать все немутабельным, пока ключевое слово (типа `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++.

ну для го 2.0 почему б идеально не сделать

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

В этом же чате и говорят, впринципе

Очень боятся повторить судьбу питона, да

ну для го 2.0 почему б идеально не сделать

я говорю в данном пропосале не только про Go 2, но и возможную backwards-compatible реализацию в Go 1.x

Хотя у него все хорошо уже. Почти)

ERROR: S client not available

ну всем хорошо не сделать

Нормальная судьба у Питона. Просто не всем знакома система версий

Это из разряда, когда люди думают что после 1.9 идет 2.0

однако были предложения наследовать иммутабельность объекта от 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 иммутабельный мап, с иммутабельным указателем на иммутабельный объект в качестве ключа на иммутабельный указатель на иммутабельный объект если кому-то данная тема интересна то буду рад обсудить аргументы за упрощённый, но ограничивающий вариант

Нормальная судьба у Питона. Просто не всем знакома система версий

Ну, еще лет 5 назад был совсем ад, когда практически все либы или поддерживали 2.7 или были только на 2.7. Просто стоит учитывать. что миграция на мажорку стоит денег и очень часто ее откладывают на тогда, когда уже нельзя терпеть.

коллеги

Мы познаем в сравнении

go не грозит судьба питона никаким образом

гугл просто наймет больше рабов и все мигрирует ?

В го менять то нечего, чтобы сломать

go не грозит судьба питона никаким образом

Даже если сделать несовместимые изменения в, скажем, go 2? В go уже такая ситуация с модулями, которые вроде как в стандарте, а у кучи либ как была версионность по коммитам, так и остается :) Или вы про другую судьбу питона?

гугл просто наймет больше рабов и все мигрирует ?

стд. библиотеку то может они и подправят, а вот community packages могут затянуться, некоторые возможно даже не перейдут на Go 2 вообще (из-за вялой поддержки пакета например) вся сложность иммено в стороннем коде, который сломают

я про то, что никто не мешает вам продолжать компилять свои поделия go1

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

а мы-то бинарники распространяем

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

я про то, что никто не мешает вам продолжать компилять свои поделия go1

невозможно будет скомпилить свой проект в Go2 с зависимостью из Go1

В языке где регистр первой буквы определяет видимость, а ошибки это просто строки херня вида const * const не пройдёт

можно же сделать 2 версии компилятора: go1 игнорит volatile и все работает как сейчас, в go2 все кроме volatile -- const ?

невозможно будет скомпилить свой проект в Go2 с зависимостью из Go1

и с++ зависимость тоже не скомпиляется

можно же сделать 2 версии компилятора: go1 игнорит volatile и все работает как сейчас, в go2 все кроме volatile -- const ?

про обратную совместимость уже всё написано в пропосале, если чего не хватает - дай знать, добавлю

это проблемой считать нельзя

это проблемой считать нельзя

ну вот допустим я вендор библиотеки, мне теперь Go2 и Go1 отдельно поддерживать? Или просто кидать пользователей Go1 и поддерживать только Go2 дабы не распылять своё внимание и время? а что если кто-то не может перейти на Go2 по каким либо причинам? т.е. нам понадобится несколько лет пока все смогут перейти медленно но верно на Go2 и всё это время мне придётся поддерживать 2 версии 1 библиотеки?

А то, что нужно вроде как следить за тем, что стоит в системе, хотя на самом деле просто entrypoint с правильной версией питона можно ставить - это считается проблемой?) Мне казалось, что проблема как раз в том, что есть новая модная версия языка, на которой хочется писать и там все круто, а есть безумное количество легаси, которое работает на языке, который стагнирует и легаси в бизнесе тянет за собой легаси в open source проектах. Ну или костыли в виде six и кучу черной магии.

Но six в go будет выглядить только как кодогенерия, на мой взгляд

ну вот допустим я вендор библиотеки, мне теперь Go2 и Go1 отдельно поддерживать? Или просто кидать пользователей Go1 и поддерживать только Go2 дабы не распылять своё внимание и время? а что если кто-то не может перейти на Go2 по каким либо причинам? т.е. нам понадобится несколько лет пока все смогут перейти медленно но верно на Go2 и всё это время мне придётся поддерживать 2 версии 1 библиотеки?

две версии поддерживать, конечно

или одну, если старую не хочешь. кому надо - тот пусть и поддерживает

две версии поддерживать, конечно

И это хорошо? Это ужасно, я вам скажу, у меня столько времени нет

две версии поддерживать, конечно

И это проблема

ну а что делать авторам java библиотек с выходом go? поддерживать две версии? забить на java? забить на go?

ну а что делать авторам java библиотек с выходом go? поддерживать две версии? забить на java? забить на go?

ну это уже немного другая ситуация, совершенно разные экосистемы