Собственно для задачи гарантированного избавления от совместных правок это и придумано.
Как мне показалось в докладе обсуждается именно проблема совместных правок.
Впрочем топик про Pg. И, судя по всему, в нем нельзя на уровне базы гарантировать неизменяемость данных другими транзакциями на необходимое время.
Можно любую ситуацию доводить до абсурда. Менять код БД на несколько порядков проще чем менять код JavaEE какой-нибудь. Об этом и говорится в статье.
Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Это не значит что надо переходить на Production Driven Development.
Это значит, что при рассмотрении конкретной ситуации, надо учитывать подобную возможность.
Если система доставки спроектирована как рассказывает VladimirVerstov
выше, то подобная возможность не будет использоваться.
Если система доставки нового кода от 4х недель и больше, то нельзя догматично отбрасывать возможность спасти больше данных заказчика прямым вмешательством (и конечно работать в сторону уменьшения времени доставки).
Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать? Теперь ограничение потребовалось. Вся суть примера в изменившихся требованиях и вариантах их реализации.
А идея добавить на скорую руку какой-то триггер, который что-то будет делать (причем, разумеется, только на проде) настолько плохая, что мне кажется, комментировать ее бессмысленно.
Идея оставить заказчика наедине с его проблемами до ближайшего релиза не предоставляя обходных решений еще хуже.
Дело не в плохости «добавить на скорую руку какой-то триггер». Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win. Бизнес доволен оперативностью и спокойно ждет оплаченную доработку. Разработка довольна, что не надо делать все аврально.
То есть вы за вариант «запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой»? просто потому что Бизнес захотел быстро?
Вариант с отсутствием доступа вообще весь тред делает бессмысленным, поэтому предлагаю его не рассматривать.
Пусть без прямого доступа, но передать временную «миграцию» отдельно от общего решения всегда можно. Отличаться от прямого доступа это будет только в части того кто будет запускать скрипт.
Бизнесу надо запретить почти всем пользователям выполнять операцию, которая раньше была вполне себе легитимной. Например сделать это новой настройкой уровня доступа. Естественно рассылаются новые должностные инструкции пользователям, согласовывается новое ТЗ/ЧТТ на изменение функционала поддерживаемой системы.
И конечно ждать его величество Бизнес очень не любит.
Что лучше?
Воткнуть триггер сегодня чтобы пользователи гарантированно перестали делать чего они не должны, и затем выкатить новый релиз по стандартной схеме?
или уповать на новые инструкции в ожидании релиза?
или запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой?
Вот поэтому я никогда и не показываю рабочие скрипты. Они обычно написаны наспех и годятся только для внутреннего пользования.
В скрипте «Информация о таблицах»
* таблица «d» джойнится только имени таблицы, когда надо джойнить по 2м полям.
* запрос раз в 10 тяжелее чем можно было бы за счет джойнов с запросами с предварительной группировкой.
Скрипт «Скрипт «Атрибутный состав таблиц»» не смог дождаться завершения при копипасте с сайте. Выключил через 2 минуты. Притом, что ожидаемый вывод 2 строки:
SCHEMA_NAME_1 TABLE_NAME_1
SCHEMA_NAME_1 TABLE_NAME_2
Поведение вызвано тем же GROUP BY.
PS. добавлю облегченный скрипт «Информация о таблицах».
WITH filter(owner, table_name)
AS (SELECT 'SCHEMA_NAME_1'
,t.*
FROM TABLE(sys.odcivarchar2list('TABLE_NAME_1', 'TABLE_NAME_2')) t
UNION ALL
SELECT owner
,table_name
FROM all_tables
WHERE owner = 'SCHEMA_NAME_2')
SELECT a.owner AS schema_name
,a.table_name
,e.comments
,b.num_rows as height
,(SELECT COUNT(1) AS width
FROM all_tab_columns x
WHERE x.owner = a.owner
AND x.table_name = a.table_name
GROUP BY owner, table_name)
width
,(SELECT LISTAGG(column_name || ' (' || data_type || ')', ', ') WITHIN GROUP (ORDER BY column_id)
AS datetime_columns
FROM all_tab_columns x
WHERE (data_type = 'DATE'
OR data_type LIKE 'TIMESTAMP%'
OR data_type LIKE 'INTERVAL%'
OR LOWER(column_name) LIKE '%period%'
OR LOWER(column_name) LIKE '%date%'
OR LOWER(column_name) LIKE '%time%')
AND x.owner = a.owner
AND x.table_name = a.table_name
GROUP BY owner, table_name)
datetime_columns
,b.avg_row_len
,(SELECT LISTAGG(column_name, ', ') WITHIN GROUP (ORDER BY column_position) AS part_key
FROM all_part_key_columns x
WHERE object_type = 'TABLE'
AND x.owner = a.owner
AND x.name = a.table_name
GROUP BY owner, name)
part_key
,(SELECT LISTAGG(column_name, ', ') WITHIN GROUP (ORDER BY column_position) AS subpart_key
FROM all_subpart_key_columns x
WHERE object_type = 'TABLE'
AND x.owner = a.owner
AND x.name = a.table_name
GROUP BY owner, name)
subpart_key
FROM filter a
LEFT JOIN all_tab_statistics b
ON a.table_name = b.table_name
AND a.owner = b.owner
AND b.object_type = 'TABLE'
LEFT JOIN all_tab_comments e
ON a.table_name = e.table_name
AND a.owner = e.owner
AND table_type = 'TABLE'
ORDER BY a.owner, a.table_name
End-to-end tests include unowned dependent services, so an end-to-end test of a Company Accounts user journey would use a System Under Test comprised of the latest Company Accounts code and a running version of Payments.
Мне кажется точнее это можно было бы перевести как «сторонние сервисы» или «чужие/внешние/третьи» но переводчик из меня так себе.
Паттерн: Автоматизируйте проверку и валидацию программного обеспечения, включив тестирование юнитов, компонентов, емкости, функционала и развертывания.
Спасибо, что дали ссылку на исходную статью. Без нее понять этот вот гуглотренслейт сложно. Тем более что дальше по тексту те же Unittest названы «Модульные тесты»
Пожалуйста выберите какую то одну терминологию в последующих переводах.
Если ПО падает не в момент внесения изменений, а в момент их фиксации — у меня для вас плохая новость, вы заигрались с DEFFERED проверками.
Единственный оправданный случай использования подобных проверок я видел в миграции данных. Остальные случаи всегда сводились к ошибкам проектирования и разработки.
ну вот ) а я думал я один куда то не туда смотрел когда фоторамку покупал… но мне всего лишь обещали «скидки всем от 500р»… с кучей (*) и прочими изобретениями сами-знаете-кого?
У Связного я точно видел ценники с облачными скидками =-). С тех пор обхожу его стороной. Простите пруфов не будет. Не коллекционирую подобные промахи.
С М.Видео хороший пример.В М.Видео меня долго и мучительно парили по скидкам и акциям перед новым годом, однако на кассе ничего из перечисленного на сайте внезапно не сработало. «не то» и «не там» и «не про то», в результате купил по полной стоимости просто потому что фиг где найдешь в предновогоднем городе нужную модель фоторамки. Но согласен, до медиамаркта им далеко. Вот уже где резвились вовсю.
Ну как же нечем? Я на каждое сообщение даю развернутый ответ, а вы всё в сторону уходите
Да, да… всегда основной ответ по делу. Спасибо кстати, очень приятно когда ответ не просто отмашка. Но аналогии всегда идут уж очень далеко от темы. Сравнивать конкурентное преимущество получаемое за счет внешнего вида и за счет 9999 или «скидки 70%» это как вы выразились красное с кислым.
Так поэтому я и написал «частично п4».
Понятие «реальная скидка» уже начинает становиться оксюмороном.
Вы так легко вешаете ярлыки. Маркетологов вы приравниваете к впаривателям и наперсточникам, а магазины для вас обманщики. Какой-то негативный взгляд на мир. Попробуйте взглянуть на ситуацию без стереотипного мышления. Не все магазины обманывают, и не все маркетологи впаривают.
Что поделать если тебя почти каждый день в почти каждом магазине пытаются обмануть или сознательно запутать.
Пятерочки, спары, дикси, ленты, океи, эльдорадо, спортмастеры, мвидео. И тысячи их, тысячи. Примеров как по сетям, так и по производителям море.
Все следуют вашим советам из статьи, и другим таким же советчикам.
Походу покупок посчитать их сумму в уме — нет что вы, для этого придумали п2 и п3. Покупатель должен внимательно осмотреть весь ценник, запомнить цену с копейками, иначе его обманет собственный моск.
Согласно п4 надо показывать скидку.
Отличить хорошую скидку по п4 от ненастоящей не занимаясь мониторингом цены на конкретный товар на длительном периоде
Сами же пишете
Другими словами, многие люди любят заключать выгодные сделки, ну или хотя бы чувствовать, что им удалось выиграть при покупке.
дополню фразу «хотя это не так»!
Пункты 1 и 5 прекрасны и показывают чем на самом деле может заниматься специалист. Однако без остальных обманок с него будут спрашивать «почему мои утюги не продаются»
Кстати про ваши велосипеды. в жизни ценники будут 21999 и 21699 и пойди запомни разницу. Уберите эти 9999 и между 22000 и 21700 разницу увидит любой покупатель, но это ведь не нужно продавцу не так ли?
Каждый первый магазин обманывает и работает только принцип «обмани или проиграешь»? Вы серьезно в это верите? Тогда вы оторваны от реальности. Всё не так плохо в этом мире :)
Добавим конкретики? Если все совсем не так плохо, то вам не составит труда указать любую торговую сеть, не использующую ни один из перечисленных приемов и не реализующую товаров производителей с указанными нарушениями?
Я писал о том, как честные цены и настоящие скидки сделать заметнее в конкурентной борьбе. В статье нет ни единого слова о впаривании или обмане.
Вы видимо под «конкурентной борьбой» понимаете использование всех этих практик «обмана» всеми подряд. Как в 90х «наши товары подлежат обязательной сертификации».
Все ваши «обязывания» это тоже глупость. Давайте тогда обяжем Мерседес делать некрасивые автомобили, а то они будут слишком хорошо продаваться. Это всё проделки злых маркетологов, которые только и хотят всех обмануть. Обяжем выглядеть Мерседесы как Лады, чтобы не обманывать пользователя красивой упаковкой :))
обозвать глупостью и снова перевести стрелки чисто на внешний вид. Видимо по сути ответить нечем да?
А ну естественно, у вас маркетологи и накрутку придумали :))
Простите а кто? Какой отдел отвечает за продвижение товаров и бренда (пере-)продавца? За отношение к бренду? Если это не отдел маркетинга — то напишите, пожалуйста, какой? а то вдруг я действительно не на тех ребят злюсь за повальный обман в сфере (пере-)продаж.
У вас какая-то ненависть прямо к маркетологам. Всех под одну гребенку. Что же вы тогда читаете статьи и пишете комментарии в хабе про маркетинг? Зачем так себя мучать и тратить время? Вы мазохист? :)
Я любознательный :) К тому же сложно назвать это мучением. Я описываю свою боль из-за действий, которые отношу к вашим профессиональным навыкам. Вы защищаете свою профессию.
Обман представляет собой умышленное введение другой стороны в заблуждение с целью вступить в сделку.
Показываете скидку которой нет = обман
Показываете цену, которую потребитель из-за особенностей работы мозга видит как меньшую = обман.
Уменьшаете часть цены, чтобы снизить внимание потребителя = обман
Показываете цветом ценника что это скидка, а скидки нет = обман
Уменьшаете объем от привычного покупателям, пользуясь опять таки особенностями работы мозга = обман
Еще раз, к моему глубочайшему сожалению, сейчас это обманом согласно УК не считается.
Я понимаю, что вы этим на жизнь себе зарабатываете и сами себя то уже давно оправдали. Наперсточники тоже угрызениями совести не мучаются, это нормально.
Как мне показалось в докладе обсуждается именно проблема совместных правок.
Впрочем топик про Pg. И, судя по всему, в нем нельзя на уровне базы гарантировать неизменяемость данных другими транзакциями на необходимое время.
select for updateнеужели в Pg нет ничего столь же удобного?
с подобным стремлением нельзя не согласиться.
Мой изначальный коммент был про то, что возможны ситуации, когда изменение кода в БД на проде даст быстрый желаемый результат без тяжелых последствий.
Это не значит что надо переходить на Production Driven Development.
Это значит, что при рассмотрении конкретной ситуации, надо учитывать подобную возможность.
Если система доставки спроектирована как рассказывает VladimirVerstov
выше, то подобная возможность не будет использоваться.
Если система доставки нового кода от 4х недель и больше, то нельзя догматично отбрасывать возможность спасти больше данных заказчика прямым вмешательством (и конечно работать в сторону уменьшения времени доставки).
Бизнес не требовал раньше подобное разграничение доступов. Почему же его надо было заранее делать? Теперь ограничение потребовалось. Вся суть примера в изменившихся требованиях и вариантах их реализации.
Идея оставить заказчика наедине с его проблемами до ближайшего релиза не предоставляя обходных решений еще хуже.
Дело не в плохости «добавить на скорую руку какой-то триггер». Если триггер взвели и одновременно с этим в системе контроля версий он тоже появился и в реализуемом постоянном решении это учтено, то получаем win-win. Бизнес доволен оперативностью и спокойно ждет оплаченную доработку. Разработка довольна, что не надо делать все аврально.
Вариант с отсутствием доступа вообще весь тред делает бессмысленным, поэтому предлагаю его не рассматривать.
Пусть без прямого доступа, но передать временную «миграцию» отдельно от общего решения всегда можно. Отличаться от прямого доступа это будет только в части того кто будет запускать скрипт.
Бизнесу надо запретить почти всем пользователям выполнять операцию, которая раньше была вполне себе легитимной. Например сделать это новой настройкой уровня доступа. Естественно рассылаются новые должностные инструкции пользователям, согласовывается новое ТЗ/ЧТТ на изменение функционала поддерживаемой системы.
И конечно ждать его величество Бизнес очень не любит.
Что лучше?
Воткнуть триггер сегодня чтобы пользователи гарантированно перестали делать чего они не должны, и затем выкатить новый релиз по стандартной схеме?
или уповать на новые инструкции в ожидании релиза?
или запускать процесс обычного нового ЧТТ/ТЗ по аварийной схеме с максимально быстрой выкаткой?
В скрипте «Информация о таблицах»
* таблица «d» джойнится только имени таблицы, когда надо джойнить по 2м полям.
* запрос раз в 10 тяжелее чем можно было бы за счет джойнов с запросами с предварительной группировкой.
Скрипт «Скрипт «Атрибутный состав таблиц»» не смог дождаться завершения при копипасте с сайте. Выключил через 2 минуты. Притом, что ожидаемый вывод 2 строки:
SCHEMA_NAME_1 TABLE_NAME_1
SCHEMA_NAME_1 TABLE_NAME_2
Поведение вызвано тем же GROUP BY.
PS. добавлю облегченный скрипт «Информация о таблицах».
А после передаваемых по наследству улучшений начнется веселуха как с железом сейчас.
Мне кажется точнее это можно было бы перевести как «сторонние сервисы» или «чужие/внешние/третьи» но переводчик из меня так себе.
Спасибо, что дали ссылку на исходную статью. Без нее понять этот вот гуглотренслейт сложно. Тем более что дальше по тексту те же Unittest названы «Модульные тесты»
Пожалуйста выберите какую то одну терминологию в последующих переводах.
Единственный оправданный случай использования подобных проверок я видел в миграции данных. Остальные случаи всегда сводились к ошибкам проектирования и разработки.
С М.Видео хороший пример.В М.Видео меня долго и мучительно парили по скидкам и акциям перед новым годом, однако на кассе ничего из перечисленного на сайте внезапно не сработало. «не то» и «не там» и «не про то», в результате купил по полной стоимости просто потому что фиг где найдешь в предновогоднем городе нужную модель фоторамки. Но согласен, до медиамаркта им далеко. Вот уже где резвились вовсю.
Да, да… всегда основной ответ по делу. Спасибо кстати, очень приятно когда ответ не просто отмашка. Но аналогии всегда идут уж очень далеко от темы. Сравнивать конкурентное преимущество получаемое за счет внешнего вида и за счет 9999 или «скидки 70%» это как вы выразились красное с кислым.
Понятие «реальная скидка» уже начинает становиться оксюмороном.
Что поделать если тебя почти каждый день в почти каждом магазине пытаются обмануть или сознательно запутать.
Пятерочки, спары, дикси, ленты, океи, эльдорадо, спортмастеры, мвидео. И тысячи их, тысячи. Примеров как по сетям, так и по производителям море.
Все следуют вашим советам из статьи, и другим таким же советчикам.
Походу покупок посчитать их сумму в уме — нет что вы, для этого придумали п2 и п3. Покупатель должен внимательно осмотреть весь ценник, запомнить цену с копейками, иначе его обманет собственный моск.
Согласно п4 надо показывать скидку.
Отличить хорошую скидку по п4 от ненастоящей не занимаясь мониторингом цены на конкретный товар на длительном периоде
Сами же пишете
дополню фразу «хотя это не так»!
Пункты 1 и 5 прекрасны и показывают чем на самом деле может заниматься специалист. Однако без остальных обманок с него будут спрашивать «почему мои утюги не продаются»
Кстати про ваши велосипеды. в жизни ценники будут 21999 и 21699 и пойди запомни разницу. Уберите эти 9999 и между 22000 и 21700 разницу увидит любой покупатель, но это ведь не нужно продавцу не так ли?
Добавим конкретики? Если все совсем не так плохо, то вам не составит труда указать любую торговую сеть, не использующую ни один из перечисленных приемов и не реализующую товаров производителей с указанными нарушениями?
Вы видимо под «конкурентной борьбой» понимаете использование всех этих практик «обмана» всеми подряд. Как в 90х «наши товары подлежат обязательной сертификации».
обозвать глупостью и снова перевести стрелки чисто на внешний вид. Видимо по сути ответить нечем да?
Простите а кто? Какой отдел отвечает за продвижение товаров и бренда (пере-)продавца? За отношение к бренду? Если это не отдел маркетинга — то напишите, пожалуйста, какой? а то вдруг я действительно не на тех ребят злюсь за повальный обман в сфере (пере-)продаж.
Я любознательный :) К тому же сложно назвать это мучением. Я описываю свою боль из-за действий, которые отношу к вашим профессиональным навыкам. Вы защищаете свою профессию.
Показываете скидку которой нет = обман
Показываете цену, которую потребитель из-за особенностей работы мозга видит как меньшую = обман.
Уменьшаете часть цены, чтобы снизить внимание потребителя = обман
Показываете цветом ценника что это скидка, а скидки нет = обман
Уменьшаете объем от привычного покупателям, пользуясь опять таки особенностями работы мозга = обман
Еще раз, к моему глубочайшему сожалению, сейчас это обманом согласно УК не считается.
Я понимаю, что вы этим на жизнь себе зарабатываете и сами себя то уже давно оправдали. Наперсточники тоже угрызениями совести не мучаются, это нормально.