В список опенсорсных SQL тулзин добавил разного на php, erlang, haskell.
Из интересного - автор ZomboDB делает депарсер постгревого AST обратно в SQL. Ни одного нормального опенсорсного решения нет.
Депарсер вроде как минорная фича, но усилий нужно приложить вагон. Респект автору!
Зачем нужен депарсер? Можно использовать для prettier’а, например. Автор делает это для своего фреймворка разработки экстеншенов под pg на rust.
В своих проектах пока приходится использовать один кривой-косой, который удалось найти. С радостью заменю его на другой :)
PS: собрал несколько парсеров для Cypher
Из интересного - автор ZomboDB делает депарсер постгревого AST обратно в SQL. Ни одного нормального опенсорсного решения нет.
Депарсер вроде как минорная фича, но усилий нужно приложить вагон. Респект автору!
Зачем нужен депарсер? Можно использовать для prettier’а, например. Автор делает это для своего фреймворка разработки экстеншенов под pg на rust.
В своих проектах пока приходится использовать один кривой-косой, который удалось найти. С радостью заменю его на другой :)
PS: собрал несколько парсеров для Cypher
Добавили cypher в parsers.dev
Потому что а почему бы и нет? :)
Cypher это такой язык для запросов по графам. Работает в neo4j, redisgraph, sap hana и нескольких других.
PS: формат дерева у существующего парсера немного странный. Если будут заявки на более приличный вид - причешем.
Потому что а почему бы и нет? :)
Cypher это такой язык для запросов по графам. Работает в neo4j, redisgraph, sap hana и нескольких других.
PS: формат дерева у существующего парсера немного странный. Если будут заявки на более приличный вид - причешем.
Если по итогам года вам показалось, что трекать часы для самого себя это перебор, то взгляните на это:
https://samplesize.one/blog/posts/my_year_in_data/
https://samplesize.one/blog/posts/my_year_in_data/
samplesize.one
My year in data
What do I actually do with my time? How productive am I? I logged everything I did in 2020 and got some pretty cool data out of this.
меня тут попросили вакансию пофорсить.
мидл фулстек js в калифорнийский стартап.
до 300к.
если кому-то интересно, стучите, отфорваржу полное описание
мидл фулстек js в калифорнийский стартап.
до 300к.
если кому-то интересно, стучите, отфорваржу полное описание
Комрадс, меня попросили пофорсить еще одну вакансию. Даже две :)
CEO и CTO в немецкий стартап по AR:
www.manuarity.com
стучите, отфорваржу на человека
CEO и CTO в немецкий стартап по AR:
www.manuarity.com
стучите, отфорваржу на человека
А давайте небольшой апдейт про holistic.dev
Как я уже говорил, мы в процессе налаживания официальных отношений со всеми основными облачными провайдерами в РФ. На данный момент с тремя из них можно быстро интегрироваться через FaaS (cloud functions - общее название aws lambda).
Для Yandex.Cloud, SberCloud и Selectel эти функции и инструкции по инсталляции можно взять в нашем гитхабе или на странице документации.
Как я уже говорил, мы в процессе налаживания официальных отношений со всеми основными облачными провайдерами в РФ. На данный момент с тремя из них можно быстро интегрироваться через FaaS (cloud functions - общее название aws lambda).
Для Yandex.Cloud, SberCloud и Selectel эти функции и инструкции по инсталляции можно взять в нашем гитхабе или на странице документации.
Как можно проконтролировать, что после рефакторинга базы и/или запросов у вас ничего не сломается?
"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.
Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов 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: смотреть необязательно :)
"Конечно, тестами!", - скажете вы.
Да. Но это не точно. Т.е. результаты не будут точными. Все сильно зависит от самих тестов. Причем даже больше от тестов с негативными сценариями.
Пример на это утверждение я приведу чуть ниже, а пока расскажу о том, что мы сделали инструмент для автоматического отслеживания изменений в типах результатов 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
Как говорится, нужно культурно расти, иначе....
Если что-то интересное будет попадаться, присылайте :)
Постоянно на глаза попадаются какие-то странные и крутые штуки - вещи, арт, архитектура, природа.
Решил запилить отдельный канал, куда буду скидывать такое:
@wellfirstofallitsbeautiful
Как говорится, нужно культурно расти, иначе....
Если что-то интересное будет попадаться, присылайте :)
Все уже забыли, что я не только про базы, но и так, про потерянные полимеры тоже... :)
Forwarded from Kedr to Earth | Земля, я Кедр (✅ Yuri Ammosov)
Оказывается, когда 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/
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/
SQL эксплорер для S3.
Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля:
https://twitter.com/phil_eaton/status/1353372050023456768
Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля:
https://twitter.com/phil_eaton/status/1353372050023456768
GitHub
GitHub - eatonphil/gosql: An early PostgreSQL implementation in Go
An early PostgreSQL implementation in Go. Contribute to eatonphil/gosql development by creating an account on GitHub.
"Опыт приходит сразу после того, как был нужен" - золотые слова :)
Облака: Выбирайте наши 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
Также облака: Расставляйте условия в 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
There will be no singularity
SQL эксплорер для S3. Пилит тот же чувак, который начал переписывать Postgresql на Go с нуля: https://twitter.com/phil_eaton/status/1353372050023456768
все уже украдено до нас (с):
https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html
https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-select.html
Amazon
SELECT Command - Amazon Simple Storage Service
Overview of the SELECT SQL command supported by Amazon S3 Select.
There will be no singularity
все уже украдено до нас (с): 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
https://aws.amazon.com/athena/
Simply point to your data in Amazon S3, define the schema, and start querying using standard SQL
Amazon
Interactive SQL - Amazon Athena - AWS
Amazon Athena is a serverless, interactive analytics service that provides a simplified and flexible way to analyze petabytes of data where it lives.