Oracle: проверка наличия ограничения на таблицу с помощью SQL-запроса

Задача

Проверить с помощью SQL, есть ли на таблице K ограничение (например, внешний ключ) с именем N.

Решение

SELECT * FROM ALL_CONSTRAINTS WHERE TABLE_NAME = 'K' AND CONSTRAINT_NAME = 'N'

Бесследное удаление КриптоПРО JCP 2.x

Под Windows:

• Сносим JDK
• Удаляем из реестра HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs\ru\/Crypto/Pro

Под Linux:

• Сносим JDK
• Удаляем /root/.java/
• Удаляем /var/opt/cprocsp/
• Если /usr/java/default не совпадает с только что снесенной JDK, то нужно удалить из нее .java/.systemPrefs/.ru (т.к. эта папка создается JCP почему-то именно в этой JDK, а не в той, куда ставится JCP)

PostgreSQL: игнорирование вставки записей в таблицу средствами СУБД

Задача

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

Решение

Создаем триггерную функцию, блокирующую вставку записи (блокировка вставки выполняется посредством возврата NULL из триггерной функции):

CREATE OR REPLACE FUNCTION nop()
RETURNS trigger AS
$BODY$
BEGIN
RETURN NULL;
END;
$BODY$
 LANGUAGE plpgsql VOLATILE
 COST 100;

Теперь вешаем эту функцию как триггер на таблицу, прописывая нужное условие, например, равенство значения определенной колонки определенной строке:

CREATE TRIGGER suppress_tr1code_rows
BEFORE INSERT ON mytable
FOR EACH ROW
WHEN (new.code = 'TR1')
EXECUTE PROCEDURE nop();

Профит! 

TortoiseHG: сохраняем логин/пароль для работы с репозиторием

Задача

Для работы с некоторым репозиторием нужно сохранить логин/пароль, чтобы он не запрашивался при каждом pull'е / push'е.

Решение

В домашней директории создаем файл .hgrc и в нем прописываем:

[auth]
myrepo.prefix = https://myrepo/repo/
myrepo.username = myusername
myrepo.password = MyPa$$W0Rd

Maven и наследование версий

Задача

Есть проект со сложной иерархией - корневая pom-ка содержит ряд модулей, каждый из модулей, в свою очередь, так является многомодульным и т.п.:

pom.xml
 |_ module1
     |_ pom.xml
     |_ submodule1
         |_ pom.xml
     |_ submodule2
         |_ pom.xml
 |_ module2
     |_ pom.xml
     |_ submdule3
         |_ pom.xml

Есть желание задавать версию всего проекта только в корневой pom-ке, чтобы все вложенные модули ее наследовали.

Однако, не все так просто, как хотелось бы. Ситуация следующая:

• Дочерний проект может не указывать в своей pom-ке версию, тогда версия подтянется из родительского проекта. И это хорошо.
• Однако, когда мы в pom-ке дочернего проекта указываем родителя, его версия является обязательной, хотя, казалось бы, при указании relativePath в этом нет необходимости - определение родительского проекта по указанному относительному пути в любом случае будет однозначным

Решение

Решение нетривиально и подсказано https://www.igorkromin.net/index.php/2015/11/08/getting-around-mavens-parent-child-project-version-dependency-issue/. В качестве версии родительского проекта во всех дочерних pom-ках указываем не конкретную версию, а диапазон версий, заведомо более широкий, чем реально возможные версии проекта:

<parent>
<groupId>somegroup</groupId>
<artifactId>someparent</artifactId>
<version>[1.0,99.0)</version>
<relativePath>../</relativePath>
</parent>

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

Подход работает на Maven 3.2.2+.