Я думаю Regis имел ввиду, что еmails — это лист, и в нем 1ый, 5ый и 27 может быть один и тот же емейл, а значит и вероятность выбора его из этого списка выше. Весь код я не смотрел, может в нем и есть защита.
За статью и опыт в этом деле — спасибо. Но как насчёт следующего:
1) Что думают сами сотрудники о review?
2) Есть ли возможность сравнить эффективность компании с ревью и без него, для понимания эффективности этого процесса?
3) Как проходит ревью самих менеджеров и лиц над ними (исключая владельцев, разумеется)?
Вы привели второй сильный аргумент в пользу табов — сжатие/растяжение кода на свой вкус. Первый — 1 символ, вместо n пробелов. На практике встречал 3 варианта: только пробелы, только табы и смешанный. Могу сказать, что подходит мне — пробелы, но не факт, что другим :) Хотя это уже сказано выше — у пробелов есть преимущество — это зрительная переносимость кода, можешь его открыть на работе, дома/ в блокноте, в ide — он все также выглядит одинаково. Можешь делать ревью в браузере — код выглядит одинаково. С табами этого добиться сложнее.
@TargetFilter из RefOrms
Указание имени параметра фильтра в аннотации поддерживает JDBI, называется правда там это аннотация Bind.
Сравнение фреймворков это дело хорошее, но боюсь выходит за рамки этой статьи
Пишешь sql-запрос, скармливаешь его движку, вуа ля и получаешь то, что нужно. Разумеется, соединение достаешь из пула, отработал таск, кладешь обратно.
Исходники открыты на гитхабе, есть артефакт в мавен централ репозитории, не вижу каких-либо противопоказаний для использования желающими :) Другое дело, что его пилить нужно, батчинг, хранимые процедуры, генерация id для insert и так по-мелочи. Присоединяйтесь, коли будет желание, пару пул реквестов я уже заапрувил.
Про угодил, не угодил я ничего в разрезе JDBI не писал. Его подход, а точнее стиль программирования очень похож c рассматриваемым решением. Он отлично покроет такие операции как INSERT, UPDATE и DELETE. Но больше всего в проектах приходится возиться с операцией SELECT. И здесь прослеживается основная разница: JDBI пошел по пути SpringTemplate — RowMapper, ColumnMapper и все такое. RefOrms пошел по пути анализа SQL-запроса, для того, чтобы мепить, фильтровать и прочие.
Лично я не против такой позиции. Но если высказали А, то нужно сказать и Б.
A — есть у Вас подготовленный String sql-запрос к БД на выборку данных.
Б — а что дальше?
if (contact.getBirthDate() != null) VALUES("birthday", "#{birthday}");
Под этим я и понимаю кодинг — именно наличие оператора if.
Разумеется, указывать сам параметр и его значение в том или ином виде при любом подходе придется, другое дело для того же батиса, кто им мешал сделать так:
// как вариант N1
VALUES("birthday", "#{birthday}?");
// или так как другой вариант N2
VALUES("birthday", "#{birthday or nothing}");
или еще, как-то, более декларативно, согласно их представлениям понятия краткости и лаконичности.
Самое главное, я ни в коем случае не пытаюсь приуменьшить значение батиса для эко системы java, не подумайте или какого-либо другого фреймворка. Более того, я даже очень рад, что нам с Вами есть что сравнивать и из чего выбирать
Когда готовил статью, я погружался в парадигму того или иного существующего фреймворка, где-то, чтобы просто освежить память, с чем-то просто никогда не работал. Мне кажется, то, что Вы называете динамическими фильтрами в MyBatis суть Dynamic SQL и кодить там все же придется, но в xml. Из достоинств Dynamic SQL — достаточно неплохой язык выражений и допускает его быстрое расширение, если потребуется. Но ключевое слово здесь кодить. С похожестью, наверное я не соглашусь, он просто другой.
А также, не пробовали получить названия параметров методов, чтобы явно не писать в аннотации TargetFilter имена
В семерке, не знаю как в 8-9, есть такой аттрибут (речь про формат .class) MethodParameters в котором есть часть, отвечающая за имя параметра:
MethodParameters_attribute {
u2 attribute_name_index;
u4 attribute_length;
u1 parameters_count;
{ u2 name_index;
u2 access_flags;
} parameters[parameters_count];
}
name_index — это индекс указывает на значение в ConstantPool, где храниться имя параметра, но в описании этого элемента имеем:
The value of the name_index item must either be zero or a valid index into
the constant_pool table.
На своем опыте скажу, что частенько встречал 0, вместо реально-ожидаемых значений. Поэтому, отвечая на Ваш 2ой вопрос, скажу НЕТ. Если же имеется альтернативный способ извлечения, подскажите, буду Вам признателен.
А вы уверены, что не потеряете при этом всю расширенную функциональность конкретной реализации?
Да нет конечно. Вы только гляньте на примерный обзор возможных конструкций в том или ином диалекте. Здесь и десятка людей не хватит, чтобы их все поддерживать. Здесь возможен на мой взгляд только компромисс и точечный выбор специфичных, но ЧАСТО используемых вещей, вроде постраничной разбивки, определенных форматов тип данных (даты, время). Возможно что-то еще. Но в целом, если придерживаться стандарта SQL-92, то думаю можно поддерживать оговоренную функциональность
Согласен и подумаю как справить. Сейчас это проблема связанна с тем, что выбор стратегии работы с типом SQL-запроса начинается задолго до непосредственного разбора самого запроса. промахнулся
Я не первый раз слышу про проблемы Kotlin и ?: и даже местами понимаю автора. Здесь вот интересно, можно ли провести аналогию с Generic в Java — определенную избыточность на уровне синтаксиса, особенно до появления Diamond Operator? Просто я помню свои возмущения когда приходилось писать полностью Map<String, String> someName = new HashMap<String, String>(); Мне таки казалось эта конструкция невозможной многословностью — ведь я сам знаю, что пишу!
Про обратную сторону ещё смело можно добавить самое главное — не видно всей картины изменений сразу, а это может привести в конечном счете к неверно выбранному пути решения основной задачи. В общем как всегда, Советы советами а жизнь диктует свои правила)
Я думаю Regis имел ввиду, что еmails — это лист, и в нем 1ый, 5ый и 27 может быть один и тот же емейл, а значит и вероятность выбора его из этого списка выше. Весь код я не смотрел, может в нем и есть защита.
За статью и опыт в этом деле — спасибо. Но как насчёт следующего:
1) Что думают сами сотрудники о review?
2) Есть ли возможность сравнить эффективность компании с ревью и без него, для понимания эффективности этого процесса?
3) Как проходит ревью самих менеджеров и лиц над ними (исключая владельцев, разумеется)?
Вы привели второй сильный аргумент в пользу табов — сжатие/растяжение кода на свой вкус. Первый — 1 символ, вместо n пробелов. На практике встречал 3 варианта: только пробелы, только табы и смешанный. Могу сказать, что подходит мне — пробелы, но не факт, что другим :) Хотя это уже сказано выше — у пробелов есть преимущество — это зрительная переносимость кода, можешь его открыть на работе, дома/ в блокноте, в ide — он все также выглядит одинаково. Можешь делать ревью в браузере — код выглядит одинаково. С табами этого добиться сложнее.
Указание имени параметра фильтра в аннотации поддерживает JDBI, называется правда там это аннотация Bind.
Сравнение фреймворков это дело хорошее, но боюсь выходит за рамки этой статьи
A — есть у Вас подготовленный String sql-запрос к БД на выборку данных.
Б — а что дальше?
Под этим я и понимаю кодинг — именно наличие оператора if.
Разумеется, указывать сам параметр и его значение в том или ином виде при любом подходе придется, другое дело для того же батиса, кто им мешал сделать так:
или еще, как-то, более декларативно, согласно их представлениям понятия краткости и лаконичности.
Самое главное, я ни в коем случае не пытаюсь приуменьшить значение батиса для эко системы java, не подумайте или какого-либо другого фреймворка. Более того, я даже очень рад, что нам с Вами есть что сравнивать и из чего выбирать
В семерке, не знаю как в 8-9, есть такой аттрибут (речь про формат .class) MethodParameters в котором есть часть, отвечающая за имя параметра:
name_index — это индекс указывает на значение в ConstantPool, где храниться имя параметра, но в описании этого элемента имеем:
The value of the name_index item must either be zero or a valid index into
the constant_pool table.
На своем опыте скажу, что частенько встречал 0, вместо реально-ожидаемых значений. Поэтому, отвечая на Ваш 2ой вопрос, скажу НЕТ. Если же имеется альтернативный способ извлечения, подскажите, буду Вам признателен.
Да нет конечно. Вы только гляньте на примерный обзор возможных конструкций в том или ином диалекте. Здесь и десятка людей не хватит, чтобы их все поддерживать. Здесь возможен на мой взгляд только компромисс и точечный выбор специфичных, но ЧАСТО используемых вещей, вроде постраничной разбивки, определенных форматов тип данных (даты, время). Возможно что-то еще. Но в целом, если придерживаться стандарта SQL-92, то думаю можно поддерживать оговоренную функциональность
Про обратную сторону ещё смело можно добавить самое главное — не видно всей картины изменений сразу, а это может привести в конечном счете к неверно выбранному пути решения основной задачи. В общем как всегда, Советы советами а жизнь диктует свои правила)
Так то оно так, но если все будут читать, кто будет писать?
Я в широком смысле придерживаюсь позиции, если берешь, то нужно и давать.