Не очень понял, для чего это делать? Реализовывать сложную логику в гетерах/сетерах? Они не предназначены для этого. Когда я вызываю color.get("#colorName"), я не ожидаю, что произойдет запуск ракеты. Когда я пытаюсь прочитать color["#colorName"], то вообще не ожидаю исполнения какой-либо логики. Зачем?
Дорогое «НЛО», то есть я правильно понимаю, что я, который с вами 10 лет, не может написать статью(они были про ActionScript! я просто серьезно не мог написать что-то новое и выдающееся про другое, ну вот опережали меня авторы фреймворков на Java и Scala и я стеснялся писать переводы про данные технологии). А в момент кризиса товарищ «EDINOROG» может писать комментарии и изменять рейтинг статей. Недостаточно кармы для голосования(да сам долбай и не делал ничего хорошего)? Можно тогда объяснить откуда у него карма? Как аккаунт с такой интересной активностью(интернет помнит))) может оставлять комментарии и влиять на рейтинг статьи?
Ну здесь очевидно, что запрос, который нужно оптимизировать — не простая выборка по какому-либо условию(для таких запросов ORM плюс-минус без ошибок). Для запросов в которых реально важна производительность — сложные выборки по многим таблицам с большим количеством условий, агрегированные таблицы в JOIN — выдрессировать ORM — задача зачастую просто нереальная. Кроме того не каждый ORM — работает прозрачно для разработчика: когда данные попадают в кэш, когда они оттуда уходят, запрос.
Приведу пример ограничений, который накладывает, допустим Hibernate на базе PostgreSQL:
— нет джойнов по полям таблиц, явно не связанными в мэппинге, допустим для такого запроса:
SELECT a.* FROM a LEFT JOIN b ON a.sum=b.sum WHERE b.type='foo';
— ORM редко когда знает о фичах самой БД. Смэпить тот же JSON/JSONB — достаточно интересная задача с собственным типом данных, а оно зачастую нужно
— никакого CTE — без костылей
— никаких хранимых процедур, нормально вписывающихся в мэппинг сущности
Использовать ORM надо с умом, и там где он применим
>> Полный peer-to-peer.
То есть у вас нет вероятности того, что кластер разделится на N подсетей? Допустим где-то маршрутизатор умер. И либо умерло все либо все живое?
И вот интересный вопрос — сложность в настройке и поддержке, ну допустим по сравнению с кроликом сильно различается?
P.S.
>> Ситуация, когда умер хотя бы один сервис — исключительная
Вот прям везет вам, что никогда оборудование не умирает)
>> По результатам наблюдения в течение 2 месяцев NATS не потерял ни одного сообщения.
Или вы не знаете о том что что-то потеряли)) Не могли бы вы рассказать о том что вы делаете в случае выхода из строя нескольких микросервисов(ситуация когда умер и получатели и отправители), спасет ли ваше логирование? Как реализован мерж после сплитбрейна? Какую пропускную способность получили?
Да с формальной точки зрения покрытие — 100%. Но вы все же кое-что забыли. Какого типа переменные a,b? В сигнатуре не указано.
А значит покрытие нужно увеличить до нескольких вариантов входных типов:
Покрытие именно строк кода тестами — метрика достаточно бесполезная, если ориентироваться только на нее. И не забываем, что тест — часть документации и контрактов между разработчиками
А тут у меня сразу по первому примеру вопрос, где сравниваются длины массивов — где там 100% покрытие? Не учтены случаи с пустым массивом, null (я совсем не питонист, не знаю какая верная формулировка), с массивами большой длинны(что-то около Long.MAX_VALUE), вызов функции без аргументов, аргументы не являются массивами.
Тест — не только проверка функциональности, но и контракт между разработчиками.
А хабр научной публикацией считается? Если да, то много :) Ну допустим человек действительно что-то стоящее сделал(свой мини-фреймворк, который упростил работу тысяч программистов). Или допустим подкаст — люди готовятся и несут знание.
Не очень понял, для чего это делать? Реализовывать сложную логику в гетерах/сетерах? Они не предназначены для этого. Когда я вызываю color.get("#colorName"), я не ожидаю, что произойдет запуск ракеты. Когда я пытаюсь прочитать color["#colorName"], то вообще не ожидаю исполнения какой-либо логики. Зачем?
Приведу пример ограничений, который накладывает, допустим Hibernate на базе PostgreSQL:
— нет джойнов по полям таблиц, явно не связанными в мэппинге, допустим для такого запроса:
— ORM редко когда знает о фичах самой БД. Смэпить тот же JSON/JSONB — достаточно интересная задача с собственным типом данных, а оно зачастую нужно
— никакого CTE — без костылей
— никаких хранимых процедур, нормально вписывающихся в мэппинг сущности
Использовать ORM надо с умом, и там где он применим
>> Полный peer-to-peer.
То есть у вас нет вероятности того, что кластер разделится на N подсетей? Допустим где-то маршрутизатор умер. И либо умерло все либо все живое?
И вот интересный вопрос — сложность в настройке и поддержке, ну допустим по сравнению с кроликом сильно различается?
P.S.
>> Ситуация, когда умер хотя бы один сервис — исключительная
Вот прям везет вам, что никогда оборудование не умирает)
Или вы не знаете о том что что-то потеряли)) Не могли бы вы рассказать о том что вы делаете в случае выхода из строя нескольких микросервисов(ситуация когда умер и получатели и отправители), спасет ли ваше логирование? Как реализован мерж после сплитбрейна? Какую пропускную способность получили?
Да с формальной точки зрения покрытие — 100%. Но вы все же кое-что забыли. Какого типа переменные a,b? В сигнатуре не указано.
А значит покрытие нужно увеличить до нескольких вариантов входных типов:
assert(?, sum(«2», «2»));
assert(?, sum('2', '2'));
assert(?, sum(2.00, 2.00));
И это минимум того что нужно сделать.
Покрытие именно строк кода тестами — метрика достаточно бесполезная, если ориентироваться только на нее. И не забываем, что тест — часть документации и контрактов между разработчиками
Тест — не только проверка функциональности, но и контракт между разработчиками.