Егор Тельнов

Проблема оказалась внутри библиотеки SocksProxyAgent. Уже не помню где читал, но где-то на GitHub писали, что такая ошибка вываливается как uncaught, потому что не висит обработчик на событии ошибки для tls.connect.
В итоге исправил

return tls.connect({
    ...omit(opts, 'host', 'hostname', 'path', 'port'),
    socket,
    servername
});

На следующий код

const tlsConnection = tls.connect({
    ...omit(opts, 'host', 'hostname', 'path', 'port'),
    socket,
    servername
});
tlsConnection.on('error', () => {
    return null;
});
return tlsConnection;

Возможно имеет смысл ещё покопаться с библиотекой в поисках более изящного решения. Пока что не работает даже если выкидывать ошибку через throw new Error(). Если найду другое решение, отпишу в комменты

onClick={ (e) => console.log(e.target.innerText) }

это же всё обычный яваскрипт

В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

Если сформулировать коротко, то разбиение на базы данных - это для администраторов БД, а разбиение на схемы - это для администраторов данных и разработчиков приложений, чтобы им же было легче.

А что будет если несколько юзеров будут на одну public-схему коннектиться?

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

Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

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

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

Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.

IMHO, самый простой вариант - временны́е слоты по 15 или 30 минут и SQL.

Допустим ты прочитаешь основы по python и sql.
И бац, делаешь запрос в БД и в запросе указываешь like твоя переменная.

Егор Тельнов, мнда.. конфуз.. ни когда не изучал контент windows.old
но на сколько я помню/понимаю:
- там нет пользовательских данных. а это важно. очень важно
- воспользоваться windows.old для восстановления, может только сама винда. в смысле 10я. при условии, что вы накатили новую версию, а потом передумали, и решили откатить
- если вы после всего этого, сделали чистую установку...

можете смело удалять windows.old как подсказывает hint000, проверьте наличие пользовательских данных. это самое важно что там может быть. про откат системы выше, а про пользовательские данные - в каменте hint000, собственно я так же их сохраняю/восстанавливаю, и не особо запариваюсь над самой виндой. ее обычно проще переустановить чем почистить. а все данные в обычных для этого папках профиля. и весь пользовательский тюнинг софта, обычно в AppData. реже бывают случаи ценной и хитрой привязки/активации софта.. но это реже ))

Что бы useEffect сработал один раз, только при активаций.
То как вы и сказали нужно передать пустой массив вторым аргументом.

useEffect(() => {
  axios
    .get("http://localhost:3001/api/score")
    .then(response => {
      if (response.data.ok) {
          dispatchDataToState(response.data);
      } else throw new Error("Server side error");
    })
    .catch(err => console.error(err));
}, []);

Думайте о втором аргументе как о зависимости для этого эффекта. Если одна из зависимостей изменилась с прошлого раза, эффект запустится снова.

Предупреждение как таковой не влияет на работу кода и функционал будет работать.

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

Или можно просто отключить предупреждение

useEffect(() => {
  // code

  // eslint-disable-next-line react-hooks/exhaustive-deps
}, []);

const fadeoutModal = () => {
  // через useState или еще как-то убираем класс visible
  // чтобы произошла анимация

  // когда анимация закончится, тогда убираем модал в родительском компоненте
  setTimeout( props.setModalHidden, 300 )
}

.....


<div
            className={classnames("modal", "visible", "fadeIn")}
            onClick={fadeoutModal}
        >

Как-то так:
js:

var someObj = {a:1,b:2};
var xhr = new XMLHttpRequest();			
xhr.open('POST', 'scratch.php');
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');			
xhr.send('param=' + JSON.stringify(someObj));
xhr.onreadystatechange = function()
{
	if (this.readyState == 4) 
	{
		if (this.status == 200)
		{
			console.log(xhr.responseText);
		}
		else
		{
			console.log('ajax error');
		}
	}
};

php:

$param = json_decode($_REQUEST["param"]);
$result = "Результат: a = ".$param->a."; b = ".$param->b;
die($result);

Вы должны удалить обработчик из функции startEarn, так как обработчик будет добавляется каждый её вызов

bot.on('callback_query', (query) => {
        workWithQuery(query, msg, randomChannel)
    });

Вам нужно добавить его один раз и уже потом обрабатывать.

Линтер ругается на useNewPost, так как это не хук, то его стоит переименовать, например, в setNewPost

Чтож, зависит от того что именно вы хотите сделать.

PostgreSQL позволяет сделать полностью собственную реализацию типа данных. Которая будет себя вести так как вы захотите - но всю эту логику вы должны разработать сами на C. Потому у create type и довольно объёмная документация.

range типы - это диапазоны. Например, дата бронирования номера гостиницы. Таблица бронирований, одно поле с диапазоном дат tsrange и exclude constraint - всё, база проконтролирует, что даты бронирования не пересекаются.

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

что-то похожее на штатные типы данных, но с ограничениями - вы хотели найти не create type, а create domain:

CREATE DOMAIN smallint_between_10and200 AS smallint CHECK(value >= 10 and value < 200);

Всё, теперь в таблицах вы можете использовать тип данных smallint_between_10and200, в который тем не менее записать что-то не из диапазона 10..200 будет невозможно.