Тут вопрос умений слоя работы с БД, если он умеет прозрачно вложенные транзакции путем сейвпоинтов, то по идее можно обернуть тест в транзакцию

Я до сих пор не понимаю людей, которые пишут тесты и вычищают базу сами. Почему нельзя тест кейс обернуть в транзакцию и откатить?

тест может представлять собой эмуляцию поведения нескольких пользователей. например: зарегился юзер 1, юзер 1 авторизовался. юзер 1сделал что-то, зарегился юзер2 юзер 2авторизовался юзер2 сделал что-то о какой одной транзакции речь?

тест может представлять собой эмуляцию поведения нескольких пользователей. например: зарегился юзер 1, юзер 1 авторизовался. юзер 1сделал что-то, зарегился юзер2 юзер 2авторизовался юзер2 сделал что-то о какой одной транзакции речь?

о транзакции, которая запускается перед началом тестов и потом по окончании делается ролбек. Но это возможно, когда тесты идут через потроха, а не через точку входа приложения. Например, кодесепшн с симфони так умеет.

хм, с таким не сталкивался пока. у меня бихат.

но просто такой тест не предусматривает зависимость от записанных данных

я в том плане, что например тестится обновление балансов, не болжно же оно зафиксировать эти изменения, если это тест.

Должно, иначе что вообще тестируется?

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

С проблем с этим обсуждение и началось

но просто такой тест не предусматривает зависимость от записанных данных

да и нет зависимости, тут вопрос когда откатывать... по сути ты транкейт+загрузку фикстур заменяешься на begin + rollback... т.е. я махнул, когда сказал про начало "тестов", начало тестА, конечно

для бихата тоже есть расширения для работы через потроха, по крайней мере с симфони и как-то там через before/afterScenario делают просто старт и ролбек транзакции

интересно. надо будет почитать на досуге.

Я до сих пор не понимаю людей, которые пишут тесты и вычищают базу сами. Почему нельзя тест кейс обернуть в транзакцию и откатить?

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

Отвертка предназначена для закручивания шурупов, а транзакции - для обеспечения консистентности данных.

Атомарность транзакции следует из требования консистентности, это особенность, а не ключевое свойство

Электричество предназначено для появления молний а не для того чтобы его люди по проводам пускали

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

Я до сих пор не понимаю людей, которые пишут тесты и вычищают базу сами. Почему нельзя тест кейс обернуть в транзакцию и откатить?

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

даже банально второе хранилище в виде какого-нибудь мемкеша сразу ломает идею "а давайте только транзакциями тестировать"

Открыли транзакцию, потестировали, почистили мемкеш, откатили транзакцию. Вроде все благородно.

что такое "почистили"? :)

его-то надо не в пустое, а в предыдущее состояние вернуть

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

после теста может быть хоть потоп

после теста может быть хоть потоп

А следующий тест на потопе производить?

его-то надо не в пустое, а в предыдущее состояние вернуть

В пустое. Если тесты работают с уже заполненной базой, то уже важен порядок тестов, они не изолированные​ уже получаются и фигня получается

А следующий тест на потопе производить?

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

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

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

Ну в реальности обеспечить изолированность друг от друга 1000 тестов трудновато. А подчистка ресурсов или откат транзакции дает по сути такую же изолированность с т.з. поведения

этим все равно не тест занимается

А если нет разницы то зачем платить больше

Ну да, система запуска тестов. А вопрос/тезис то в чем?

Sequence не откатывается в постгресе. Логика некоторых тестов может опираться на определенную последовательность.

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

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

Это не цель теста, а необязательное требование. Давайте, прогоните мне многопользовательский нагрузочный тест в OLTP-профиле внутри транзакции.

Sequence не откатывается в постгресе. Логика некоторых тестов может опираться на определенную последовательность.

вот и хорошо, сразу и плохой дизайн "опирания на значение счетчика" отсеется ;)

Это не цель теста, а необязательное требование. Давайте, прогоните мне многопользовательский нагрузочный тест в OLTP-профиле внутри транзакции.

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

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

Это у вас проблема. А у меня тестовая среда формируется клонированием продуктивной.

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

Andrey, в чем эссенциале ваших сообщений?? Причем тут нагрузочное тестирование когда мы говорим о функциональном? Кто ставит эти необязательные требования? Ребята с форума? Поток сознанкия какой-то.

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

на самом деле тесты бывают двух видов - хорошие и хреновые ;)

Andrey, в чем эссенциале ваших сообщений?? Причем тут нагрузочное тестирование когда мы говорим о функциональном? Кто ставит эти необязательные требования? Ребята с форума? Поток сознанкия какой-то.

кто говорит о функциональном? Мне кажется, вы думаете, что говорите о функциональном.

вот и хорошо, сразу и плохой дизайн "опирания на значение счетчика" отсеется ;)

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

на самом деле тесты бывают двух видов - хорошие и хреновые ;)

Не согласен. Еще бывает тест на беременность.

Например прочтите 4 предложение.

приветствую всех. Господа, есть вопрос. Пишу проект, решил сменить БД с MySQL на PostgreSQL. Пока все хорошо, кроме одного момента. В функциональных тестах на каждый сценарий делаю TRUNCATE с cascade=true. И вот, что-то на постгресе транкейт отнимает прилично времени - 25сек. для каждого сценария. Есть какие-то лайфхаки, что подтюнить, чтобы сократить это время? Мб заменить на DELETE FROM table; VACCUUM (FULL, ANALYZE) table; Что посоветуете?

Не согласен. Еще бывает тест на беременность.

Он тоже бывает хороший и хреновый, но тут субъектвно. А вы со своими нагрузочными тестами вообще не очень в кассу встряли

нагрузочный тест на беременность [x]

Он тоже бывает хороший и хреновый, но тут субъектвно. А вы со своими нагрузочными тестами вообще не очень в кассу встряли

Вы путаете сам тест и его результат.

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

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

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

> это уже не костыль , а технологический крепеж ?

> это уже не костыль , а технологический крепеж ?

О! Буду теперь так и говорить всем. ? Что это технологический крепёж очень большой важности.

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

Или я что-то не так понимаю?

Есть в postgres эта функция с 9.2. (частично). Но ее применение и сама методология мне до конца не ясна.

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

не только. Есть модель Белла - Лападулы https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%91%D0%B5%D0%BB%D0%BB%D0%B0_%E2%80%94_%D0%9B%D0%B0%D0%BF%D0%B0%D0%B4%D1%83%D0%BB%D1%8B

Так, но получается что субъект не может создавать объект с более низким уровнем досутпа.

не только. Есть модель Белла - Лападулы https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%91%D0%B5%D0%BB%D0%BB%D0%B0_%E2%80%94_%D0%9B%D0%B0%D0%BF%D0%B0%D0%B4%D1%83%D0%BB%D1%8B

Как это вообще решается только по пачкам политик безопасности. Модель описывает запись и чтение. Но не переопределение и указание доступа. Я же правильно понимаю, что указание уровня доступа документа закладыватся еще и алгоритмами, а не простого указания политики безопасности, как это происходит в дескреционном контроле доступа?

То есть в случае мандатного доступа субъект не только не может указывать права доступа к объекту. Он вообще ничего не может. Система сама решает какого уровня объект и кто может его смотреть.

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

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

Ну то есть допустим субъект зашел с более высоким уровнем доступа, создал объект. У него есть возможность понизить уровень доступа к объекту до доступного ему минимума?

мне кажется, он не сможет этого сделать. Но я могу ошибаться

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

То есть только вверх. Ни шагу вниз ?

А как тогда происходит понижение уровня доступа к объекту и предоставление доступа другим департаментам? Пересозданием копии объекта?

ERROR: S client not available

мне кажется, что изменить на доступ вниз, можно (но уже другими инструментами). Основной посыл не делать этого при создании объекта, чтобы по ошибке не дать права субъектам, у которых уровень доступа ниже. Но могу и ошибаться.

понижать сможет суперпользователь какой-нибудь :) Но не обычные пользователи. У документа кроме уровня доступа, также есть категории, по этим категориям можно определять, у каких департаментов есть доступ к документу.

понижать сможет суперпользователь какой-нибудь :) Но не обычные пользователи. У документа кроме уровня доступа, также есть категории, по этим категориям можно определять, у каких департаментов есть доступ к документу.

Вот тут я тоже путаюсь. Ведть категории или группы - являются частью дискреционной политики?

Вот тут я тоже путаюсь. Ведть категории или группы - являются частью дискреционной политики?

Всё, понял. Вопрос отпал сам собой. Группы и тут есть.

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

а в мандатной политике он не сможет менять категории

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

ясно. спасибо

Спасибо большое. С чего началось то. В postgres c версии 9.2 якобы есть поддержка мандатного управления доступом в связке с SELinux. Вот с женой за чашкой чая и начался разговор об этом. Потом чуть глубже ушли и загооворили о том возможно ли это реализовать на уровне БД без использования SELinux и как это реализуемо. А вот когда оба челвоека не на 100% понимают тему, возникают "дискуссии" ?

ясно. спасибо

пожалуйста :)

Спасибо большое. С чего началось то. В postgres c версии 9.2 якобы есть поддержка мандатного управления доступом в связке с SELinux. Вот с женой за чашкой чая и начался разговор об этом. Потом чуть глубже ушли и загооворили о том возможно ли это реализовать на уровне БД без использования SELinux и как это реализуемо. А вот когда оба челвоека не на 100% понимают тему, возникают "дискуссии" ?

без SELinux и sepgsql, мне кажется не получится это сделать. Сейчас у PostgreSQL есть Row Level Security, но мне кажется он недостаточно гибкий для мандатных политик. Но могу ошибаться

в Astra Linux есть патченный постгрес, там без SELinux, но он я думаю платный

Он еще и отдельных юзеров требует, это много соединений

Может быть очень много под нагрузкой

Он еще и отдельных юзеров требует, это много соединений

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

Хотя глупый вопрос. Атомарен. Иначе нормализации нет

По идее реалзиация мандатного доступа в postgres решается более глобальным программно-аппаратным комплексом, а не самой субд

Я прав?

Я не оч понял твои вопросы. Row level security в доке постгреса это называется

Я не оч понял твои вопросы. Row level security в доке постгреса это называется

У постгрис это security label. Нет в ней встроенрого мандатного доступа. По поводу row security level - это только триггер по своей сути. А не алгоритм.

Спасибо большое. С чего началось то. В postgres c версии 9.2 якобы есть поддержка мандатного управления доступом в связке с SELinux. Вот с женой за чашкой чая и начался разговор об этом. Потом чуть глубже ушли и загооворили о том возможно ли это реализовать на уровне БД без использования SELinux и как это реализуемо. А вот когда оба челвоека не на 100% понимают тему, возникают "дискуссии" ?

А оно вообще зачем тебе сдалось?

А оно вообще зачем тебе сдалось?

Когда дети у тещи, поднимаются все темы, которые беспокоили не один месяц

Когда дети у тещи, поднимаются все темы, которые беспокоили не один месяц

За чаем поговорить о мандатке ?

Есть CRM клиента, там дискреционный контроль доступа, обсуждали с женой возможность перебраться на мандатку, т.к. сейчас разделение доступа уже реализуется больше алгоритмами на основе меток строк, чем простым "пользователь" - "группа"

М.б. полезно кому-нибудь будет. Во время обсуждения нарвались на старую статейку (аж 2002, но всеравно хорошая) в инете по поводу доступов http://citforum.ru/security/articles/safe_db/

За чаем поговорить о мандатке ?

Ну не о друзьях же сплетничать ?

Подскажите, а насколько плохая идея использовать индекс по hash(text_field) вместо обычных b-tree? постгря 9.6. WARNING: hash indexes are not WAL-logged and their use is discouraged я правильно понимаю, что если не wal-logged, то при сбое индекс не восстановится? это, вроде, не критично, потому что щас он создался за <1 сек, а аналогичный запрос на создание b-tree индекса проработал больше часа (таблица с ~300к строк), я задолбался ждать и отменил.

как вообще лучше поступить в таком случае? поле с utf-8 строчкой размером в среднем ~30 символов. хочется быстрые селекты со сравнением "=" по этой строчке. ни лайков, ничего такого.

поменял столбцу LC_COLLATE с "en_US.UTF-8" на "C.UTF-8" и, похоже, стало прям отлично вообще. это чем-нибудь чревато в моем случае?(

Вот честно ничего по этому поводу сказать не могу ?

Ребят, подскажите пожалуйста. Есть такая таблица id json 1 [{value: 1, bool: true}, {value: 2, bool: true}] 2 [{value: 1, bool: false}, {value: 3, bool: true}] 3 [{value: 3, bool: false}] мне в результате нужны записи (id, value) в тех случаях, когда внутри json объекта bool: true. тоесть результат должен быть такой id value ---- ------- 1 1 1 2 2 3 json_array_elements(json)->>'value' отлично справляется с тем что бы вывести все значения Value, но к сожалению нельзя добавить нигде условия, что бы выводило только в случае WHEN bool = true.

Ребят, подскажите пожалуйста. Есть такая таблица id json 1 [{value: 1, bool: true}, {value: 2, bool: true}] 2 [{value: 1, bool: false}, {value: 3, bool: true}] 3 [{value: 3, bool: false}] мне в результате нужны записи (id, value) в тех случаях, когда внутри json объекта bool: true. тоесть результат должен быть такой id value ---- ------- 1 1 1 2 2 3 json_array_elements(json)->>'value' отлично справляется с тем что бы вывести все значения Value, но к сожалению нельзя добавить нигде условия, что бы выводило только в случае WHEN bool = true.

when или while?