Чтобы не вышло как в последней новости, вот, держите:

https://news.1rj.ru/str/leftjoin/223

​Как можно проконтролировать, что после рефакторинга базы и/или запросов у вас ничего не сломается?

"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.

Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов SQL запросов на основе parsers.dev!

Как он работает и кому нужен?

Надеюсь, что те, кто пишет запросы руками, хранит каждый запрос в отдельном файле. Если нет, рекомендую срочно начать это делать!

Итак, запросы у вас разложены по файлам, описание схемы тоже разложено по файлам с миграциями.
Актуальный код запушен в гит, изменения пока на локальной машине.
Запускаем скрипт с указанием расположения папок со схемой и запросами и получаем на выходе информацию о том, что изменилось с последнего пуша!

Отслеживаются:
- типы полей в результатах каждого запроса
- возможность каждого поля в ответе принимать значение NULL
- расхождения в источниках данных
- класс количества строк результата (NONE, ONE, ONE_OR_NONE, MANY, MANY_OR_NONE)

В описании пакета есть несколько примеров с гифками, поэтому предлагаю незамедлительно ознакомиться и попробовать! https://github.com/parsers-dev/sql-type-tracker

А пока пример на утверждение про тесты.

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

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

Правильные ответы - ХЗ, ХЗ и еще раз ХЗ.
Кажется, что самый важный из этих вопросов - последний. И ответ на него зависит от того как у вас устроены интеграционные тесты. Но в абсолютном большинстве случаев тесты ничего не покажут.

А чем нам это может грозить?
- в приложение попадут NULL в те места, где проверки на NULL нет
- джойны вместо 1 записи могут теперь выдавать 0 или наоборот много записей

В старых тестах все отлично - там мы эту ситуацию не ожидаем. По уму необходимо взять все существующие тесты и дописать на каждый кейс, который затрагивается этим NULL'ом, дополнительные тесты.
А какие кейсы затрагиваются этим NULL'ом?
И тут оказывается, что важными были все три вопроса...
И ответы появятся только на проде и только когда по новой фиче польются данные. В ночь с пятницы на субботу :)

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

Кстати, я надеюсь, что вы проверяете класс количества строк результата в приложении? :)

Давайте еще уточним, что этот NULL появился из-за нормализации данных, например. И там, где у нас данные тянулись из 1 таблицы, теперь они тянутся из двух. Нам нужно переписать Все запросы, где такое происходит.
Ок, не вопрос. Грепаем по имени таблицы все запросы и идем править.
И случайно в процессе копипасты, у нас в результат запроса попадает не то поле, которое нужно, а поле с таким же именем из другой таблицы. Тут id, там id... И типы одинаковые. И NULL'ов нет. Но данные теперь скомпрометированы!

Вот бы круто, если бы такое изменение можно было найти автоматом...

Ну вы поняли? https://github.com/parsers-dev/sql-type-tracker :)

Лайк, шер, пулл-реквест :)

PS: на higload2019 я делал доклад на эту тему.
PPS: смотреть необязательно :)

​Ну, во-первых, это красиво...

Постоянно на глаза попадаются какие-то странные и крутые штуки - вещи, арт, архитектура, природа.
Решил запилить отдельный канал, куда буду скидывать такое:

@wellfirstofallitsbeautiful

Как говорится, нужно культурно расти, иначе....

Если что-то интересное будет попадаться, присылайте :)

Все уже забыли, что я не только про базы, но и так, про потерянные полимеры тоже... :)

Оказывается, когда Adobe недавно окончательно и глобально отключил Flash... в Китае на целый день перестала работать железная дорога в Даляне. У них все управление через Flash делалось - расписание, формирование составов, путевые операции... Айтишники решили проблему, поставив пиратку Flash.

https://verietyinfo.com/taiwaneng/after-disabling-adobe-flash-trains-in-dalian-china-could-hardly-open-technews-%E7%A7%91%E6%8A%80-%E6%96%B0-%E6%8A%A5/

Не флеш, но тоже хорошо (featured by @oleg_log):

https://2020game.io/

SQL эксплорер для S3.
Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля:

https://twitter.com/phil_eaton/status/1353372050023456768

"Опыт приходит сразу после того, как был нужен" - золотые слова :)

​Облака: Выбирайте наши managed продукты! Мы возьмем с вас в вагон денег, но за это вам будет доступна вся наша экспертиза!

Также облака: Расставляйте условия в WHERE в оптимальном порядке сами, мы за вас еще тут думать должны?!

Bigquery assumes that the user has provided the best order of expressions in the WHERE clause, and does not attempt to reorder expressions. Expressions in your WHERE clauses should be ordered with the most selective expression first.

https://wklytech.medium.com/bigquery-sql-optimization-c7a7db170c56

​Кто должен купить гитхаб, чтоб там появились папки?

все уже украдено до нас (с):

https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html

и еще:
https://aws.amazon.com/athena/

Simply point to your data in Amazon S3, define the schema, and start querying using standard SQL

​Решил я тут с flow перебраться на typenoscript.

"Хватит извращений и закопали стюардессу" (c) анекдот

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

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

Пока наблюдения такие:
- нет exact типов. Их попросили 4 года назад!!! flow / typenoscript

- не понимает фильтрацию null'ов. flow / tуpenoscript

- flow умеет матчить файлы с json с типами, указанными в приложении, ts нет:

const a:ConfigType = require('./config.json')

И это я только начал :)

3.5 года назад был вот такой видос со сравнением typenoscript vs flow. Такое ощущение, что ms недалеко продвинулись c того времени...


Меня люто бомбит, что никто из них не ругается на

[{}].includes('wtf?!')

Сколько времени было убито на дебаг...

Короче, буду держать вас в курсе :)

"хватит извращений и закопали стюардессу"
--- сейчас вы находитесь здесь ---
"хватит извращений и откопали стюардессу"

PS: еще про тулинг. Поставил tabnine. Он даже помогает. Подозреваю, что еще немножко обучится и будет совсем хорошо.
PPS: есть еще такая тулза от отечественного производителя. Я как-то пробовал, у меня не завелось. Надо будет еще разок...

​На последний пост flow vs typenoscript приехала пояснительная бригада и в каментах накидала хаков. Делюсь:

1) хак на exact типы
2) фильтрация на null
3) json не типизируется через require, но типизируется через import
4)

[{}].includes('wtf?!')

действительно не работает, но если будет не пустой объект, а что-то понятное, то все будет ок (во flow, кстати, не будет)

Продолжаю наблюдение...

Я, оказывается, уже как-то бомбил про includes :)

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

https://news.1rj.ru/str/nosingularity/261

MIT 6.824: Distributed Systems

https://www.youtube.com/channel/UC_7WrbZTCODu1o_kfUMq88g/playlists

​А теперь и на виджете...

https://apps.apple.com/ru/app/github/id1477376905

Гляньте по ссылке в твите исходники WebKit
Cтолько захардкоженных доменов и хаков для них вы ещё не видели

https://twitter.com/jordwalke/status/1355681285717385217