Общаться с базами по сети. Я это уже не пробовал. У меня боты stateless.

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

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

похоже

А там вендор-лок на платформу, да.

Ну хотя нет

Зависимости устанавливать можно

Телеграм-библиотека у меня подключна.

А транзакции?

Я не знаю.

Ок

Ну да. Но мне же надо куда-то данные сохранять

В облако к ним

Ну как, повесить один middleware на все десять функций апи. Или ещё что

Ну вешай. У тебя одна входная функция. Из нее сам подключай мидлвари и раскидывай реквесты по подфункциям.

Ну вешай. У тебя одна входная функция. Из нее сам подключай мидлвари и раскидывай реквесты по подфункциям.

Ну ладно. Это решаемо, хотя конечно кода становится больше

Ну и с обычной базой я по сети общаюсь.

И базу у них держишь

А транзакции?

А что мешает транзакции в http делать в рамках сессии?)

А что мешает транзакции в http делать в рамках сессии?)

Это как?

Ну, в реальности транзакции же находятся в самой бд. Достаточно просто сначала делать условный login и получать идентификатор сессии, с которым дальше ходить в бд. И транзакции не будут проблемой, как мне кажется. В копилку к этому есть websocket или keep-alive штуки

А что мешает транзакции в http делать в рамках сессии?)

Вот мне надо сделать два апдейта в БД в рамках одной транзакции и между ними ещё что-то. В постгресе я пишу update в базе; что-то на сервере; update в базе; commit.

Ну, в реальности транзакции же находятся в самой бд. Достаточно просто сначала делать условный login и получать идентификатор сессии, с которым дальше ходить в бд. И транзакции не будут проблемой, как мне кажется. В копилку к этому есть websocket или keep-alive штуки

Так а если база уже готовая по http ждёт ответа?

То есть?

А хз

Чёт все что не гуглю про js

Ну, в рамках http можно сделать так: 1. login -> получен токен 2. выполняешь запрос c условным {'session': 'token', 'query': 'BEGIN TRANSACTION'} 3. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE required'} 4. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE another'} 5. выполняешь запрос c условным {'session': 'token', 'query': 'COMMIT'}

То есть это не очень эффективно, но технически не проблема

Для лучшей эффективности можно применять всякий keep-alived, что бы коннект устанавливался быстрее, но тут опять остается вопрос про "бинарный формат быстрее, чем текстовый"

Ну, в рамках http можно сделать так: 1. login -> получен токен 2. выполняешь запрос c условным {'session': 'token', 'query': 'BEGIN TRANSACTION'} 3. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE required'} 4. выполняешь запрос c условным {'session': 'token', 'query': 'UPDATE another'} 5. выполняешь запрос c условным {'session': 'token', 'query': 'COMMIT'}

И куда же я буду данные класть между запросами?

В редис. =)

В редис. =)

Тогда у меня в БД не будет транзакции

И куда же я буду данные класть между запросами?

В плане? Запросы же выполняются в бд

Результаты запросов тебе приходят в ответе на запрос

Результаты запросов тебе приходят в ответе на запрос

Надо токен сессионный хранить

На самом деле я не знаю, как разруливают продвинутые кейсы в такой архитектуре. Но как-то разруливают.

В плане? Запросы же выполняются в бд

Ну я буду в БД открывать транзакцию и ждать повторных запросов? Никаких гарантий что следующий запрос по http прилетит в тот же инстанс сервеоа

На самом деле я не знаю, как разруливают продвинутые кейсы в такой архитектуре. Но как-то разруливают.

Не делают транзакции по http

Меняют логику так чтобы они не нужны были

Ну я буду в БД открывать транзакцию и ждать повторных запросов? Никаких гарантий что следующий запрос по http прилетит в тот же инстанс сервеоа

Обычно в такой схеме запросы просто роутятся внутри кластера

Но транзакции БД остаются

Обычно в такой схеме запросы просто роутятся внутри кластера

Нет, ты не понял. Сделать два апдейта в одной транзакции и два в двух - разные вещи.

Юзать одну транзакцию БД из двух коннектов невозможно

Юзать один Коннект с двух серверов - невозможно

Гарантировать что два хттп запроса придут на один сервер - невозможно

Невозможно - у вас есть какие-то физические ограничения, которые это запрещают?

У вас есть роутинг внутри кластера

Невозможно - у вас есть какие-то физические ограничения, которые это запрещают?

Да. Протокол Http это запрещает

Вы же понимаете, что можно не привязать транзакцию к коннекту?

Вы же понимаете, что можно не привязать транзакцию к коннекту?

Как же?

Давай в постгресе или мускуле

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

Про любую тебе известную реляционную

К которой умник решил дать доступ по хттп

Любая известная мне реляционная вроде не умеет в http

Если мы говорим про прокси между пользователем и postgres - это вполне возможно

Достаточно просто что бы у этих прокси была полная связность и они могли роутить друг на друга запросы

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

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

Очень странный хттп

Я понимаю ещё вебсокет

Короче, мы поняли. Надо ещё балансировщик хитрый очень

Ок

Ну, то есть так будут делать только наркоманы, но технически это возможно)

Почему-то pip install pygame выдаёт ошибку

Ошыбку

ERROR: S client not available

бывает

иногда я вместо pip install пишу pip isntall и тоже ошибка

Почему-то pip install pygame выдаёт ошибку

попробуйте сменить прокладку между стулом и монитором.

Гарантировать что два хттп запроса придут на один сервер - невозможно

sticky session

попробуйте сменить прокладку между стулом и монитором.

Юзера?

sticky session

ну это ж все равно не гарантирует

или он если не смог доставить на тот же сервер вернет ошибку юзеру?

ну это ж все равно не гарантирует

ну эти гарантии должен reverse-proxy давать

И пайтон перестал работать правильно

или он если не смог доставить на тот же сервер вернет ошибку юзеру?

хз, наверное, это от конфигурации зависит, я этого не делал никогда

но nginx это как-то поддерживает

вчера был ужасный день, сначала заставили с 1с знакомится, потом с выгрузкой разобраться и финалом стало что мне нужно было на пхп что-то сделать. Самое ужасное что пхп 7.0 не заработал с нгинксом и выдавал стабильно 502. Стэк оверфлоу и гугл не помогли:(

где нужны только питоноводы, чтоб не было вот этого вот всего?

Хорошо вам. А я безработный

На апворке вообще сплошные нейронки сейчас

в городе только 4 нормальных вакансии питоновода

какой город?

и то фулстэк

Ростов-на-Дону

Ростов-на-Дону

приезжай в москву

тут полно вакансий

И она таки резиновая

приезжай в москву

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

О, это же тот самый синдром. Только недавно про него читал где-то. По поводу того, что постоянно есть ощущение, что скилл совсем слаб и лучше посильнее подготовиться и только потом идти по собеседованиям ?

О, это же тот самый синдром. Только недавно про него читал где-то. По поводу того, что постоянно есть ощущение, что скилл совсем слаб и лучше посильнее подготовиться и только потом идти по собеседованиям ?

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

О, это же тот самый синдром. Только недавно про него читал где-то. По поводу того, что постоянно есть ощущение, что скилл совсем слаб и лучше посильнее подготовиться и только потом идти по собеседованиям ?

я от него сейчас страдаю

хотя не, не от него

у меня синдром самозванца