+

Это не connection

А класс который делает http запросы и получает ответ.

То есть высокоуровнево можно думать что это как соединение, но на самом деле это просто http реквесты с парсингом ответа

Например с UFCS методами кодер сможет добавлять свои методы в апи в таком же стиле, достаточно будет ему описать в своем файле Message someNewMethod(BotApi botApi, int param1)

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

Так что не парься раньше времени.

То есть высокоуровнево можно думать что это как соединение, но на самом деле это просто http реквесты с парсингом ответа

Согласен, но это и не BotApi. Некое "Надсоединение".

в принципе можно и Connection обозвать. Сокеты ведь тоже не всегда tcp/ip сокеты.

Почему не BotApi ? =)

Везде во всех либах это называется Api

неа

Везде во всех либах это называется Api

ну не совсем

Хотя, это может быть Bot

т.к. в конструктор принимается токен конкретного бота

нет не бот

ты именно соединение с ботом описываешь.

это Telega

Это не соединение =)

Класс ни с кем не соединеяется.

чтобы над именем не думать долго, можно по имени либы сделать

соединение уровня приложения

mosquitto так сделали, например (первое что вспомнилось)

А если я выполню botApi.sendMessage(123, "test") то это не создаст никакого соединения, просто сделает запрос на отправку сообщения

Это больше похоже на UDP

А если я выполню botApi.sendMessage(123, "test") то это не создаст никакого соединения, просто сделает запрос на отправку сообщения

Именно, но botApi.typeof == Connection ?

через соединение шлёшь сообщение

озвучу первую мысль: не париться и напилить всё внутрь класса, оставить BotApi

а в каменте написать что оно maintains a connection to Telegram API

Когда там будет 3000 строк вы по другому заговорите )

ещё почему botApi это соединение - оно может эксепшен выкинуть насчёт потери соединения? (скорее всего), и его надо будет передёргивать.

Соединение нельзя потерять, но можно словить какую-нибудь ошибку во время установления https соединения

Скажем, этот класс делает много соединений в процессе своей работы

ну вот, это таки соединение

на уровне OSI "приложение"

всё норм, делай TelegramBotConnection

Когда там будет 3000 строк вы по другому заговорите )

std.stdio.File почти 3к (тесты, доки, код) строк, но ведь сорцы не читает никто (изредка и только конкретные вещи), всё самое важное в доке

Если в монге нет транзакций то нет и блокировок?

это разные вещи

Если в монге нет транзакций то нет и блокировок?

Ещё хуже - данные просто испортятся

А можешь на пальцах объяснить как работает for update?

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

нужно только для многоэтажных запросов или может для хранимок ещё

> пока дочерний запрос не пройдёт транзакция

защищает от аномалий когда куча уродов долбится в одну сущность в базе с какими-то изменениями.

требующими сначала селекта, потом вдумчивой обработки и только потом updat-а

да, это нужно только если данные меняются.

Транзакция же может содержать и селекты и апдейты одновременно?

да

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

Но если в этот момент чисто технически может быть апдейт, то надо?

не так. если в твоём коде будет апдейт ниже то в данном селекте надо сделать for update

если 3 этажа то смотри зависит ли от текущих выбранных данных апдейт или нет

если зависит то ставь

Типа пока апдейт не завершится селект не делать?

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

чтобы они случайно не прочитали данные которые ты уже прочитал селектом но ещё не изменил апдейтом

(они этого никак не замечают)

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

Я не совсем понял, а я разве в своем сообщении другой кейс какой то описал? Просто вроде бы мы про одно и тоже или нет?

ну я думал ты про свой текущий селект

а не про параллельные

Запросы в очередь как то ставятся?

Всем привет. А кто-нибудь работал тут с puppet?

Запросы в очередь как то ставятся?

сложнее - планировщик решает как правильно всё вытащить. а блокировка это просто флаг напротив строки таблицы

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

ERROR: S client not available

?

Ну типа попытка сделать апрейт во время селекта лишь единичный пример?

остальное не влияет на целостность данных же

select не меняет данные, insert не трогает существующую строку, delete уничтожает но и пофиг

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

Почитай еще про уровни изоляции. И это все не совсем относится к блокировкам

Блокировки они и в тредах дишных допустим есть. Всякие мьютексы.

лучше всего SQL изучать при написании бухгалтерии

пару раз ошибёшься на миллион - быстро всё поймёшь)

@DmitryBubnenkov у ПостгресПро лежит русский перевод мануала к постгресу https://postgrespro.ru/docs/postgresql/10/index Он актуальный.

Причем ошибаться на миллион совсем не сложно.

канеш! такой вот параллельной транзакцией с косяком списать дважды что-то и всё

О главнейшей причине существования современных JS-фреймворков / Хабрахабр https://habrahabr.ru/company/ruvds/blog/353074/

Автор чуток не додумал - можно фронтенд автоматически генерировать и всё будет синхронизировано. Теоретически.

Радует что начали понимать люди

Автор чуток не додумал - можно фронтенд автоматически генерировать и всё будет синхронизировано. Теоретически.

Template engine так и делают))

О главнейшей причине существования современных JS-фреймворков / Хабрахабр https://habrahabr.ru/company/ruvds/blog/353074/

Как то кэпски

Все давно знают, что модель надо синхронизировать с вьюхой

Просто в вебе эта проблема стоит наиболее остро

синхронноть и restful - тут нужно или крестик снимать, или штаны натягивать.

Какие альтернативы?

Может просто опыт десктопных гуи фреймворков в веб перенести, а синкать состояния через какие нить веб-сокеты?

Может просто опыт десктопных гуи фреймворков в веб перенести, а синкать состояния через какие нить веб-сокеты?

Про опыт десктопных гуи фреймов поподробнее

На десктопе сервер может дёргать клиента.

На десктопе сервер может дёргать клиента.

И?

Многие вещи упрощаются.

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

"десктоп" - условно

На десктопе проблемы иного плана

Какие?

Многопоточность, асинхроность

И тому подобное