Немного оффтоп: а вы уверены, что хотите сделать такую операцию по изменению данных, при то том что вам не гарантируется атомарность её исполнения и в случае ошибки у вас нет возможности определить, к каким записям в базе она была применена, а к каким нет? )
Стало немного лучше, так как есть (в теории) возможность хотя бы по ссылкам прочитать о чем речь, но статья всё еще не подходит для широкой и довольно разношерстной аудитории Хабра. Все еще нет полноценного введения в проблематику, хотя уже можно ознакомиться с ней. Кстати, в большинстве ссылкок форма подачи информации намного лучше.
Пожалуй, основная проблема — тематика уж очень далека от основной аудитории Хабра.
Не могли бы Вы объяснить, что Вы имеете ввиду? Пулл нулевого размера — это и есть дефакто отсутствие пулинга. (если просто убрать настройку пулинга, то будет использоваться default value 1 и это как раз то, что делать совсем не стоит).
Я подразумевал, что отключенный пуллинг и пул нулевого размера — не одно и тоже. Во втором случае остается оверхэд на оборачивание всех вспомогательных JDBC объектов в прокси пула.
Просмотрел бегло актуальные доки — судя по всему, со времен отделения c3p0 от самого Hibernate, hibernate.connection.pool_size со значением 0 именно отключает встроенный пул и вроде бы действительно отключает все дополнительные механизмы, нужные для пуллинга.
В Guava на каждом методе c transform в JavaDoc написано, что transform создает View, а не новую коллекцию. В документации и примеры на это, и пояснения для чего так, и что делать если там нужна именно копия. Не читаем, осуждаем. ССЗБ? Да.
Второй пример — вообще смешно. Вы выделили жирным «then»часть предложения, но почему-то не «if» :)
Ваш случай подпадал под один вариант, а вы выбрали другой. И пишете, что документация плохая :)
PS; Вместо того, чтобы использовать коннекшн пул нулевого размера — может лучше его всё же полностью убрать? :)
PS2: Статью следовало бы назвать «Даже усли использовать хорошие библиотеки, вы всё равно можете выстрелить себе в ногу» :)
catch(ValidationException e){
return new Response(400, e.getMessage());
}
catch(AccessDeniedException e){
return new Response(403, e.getMessage());
}
catch(ResourceNotFoundException e){
return new Response(404, e.getMessage());
}
catch(ApplicationNameException e){
LOGGER.error("Unknown error", e.getMessage());
return new Response(500, "Oops");
}
Почему 3 первых обработчика не объединены в один? Ах, код ошибки разный! Но ведь определение кода ошибки как и построение ответов для ошибок 4xx можно вынести в отдельный метод. Точно так же как мы поступаем с любым дублирующимся кодом. Почему на catch блоки нельзя распространить обычные практики?
Вы всегда читаете JavaDoc ко всем методам сторонних либ, которые используете? Скорее всего нет. Представьте, что како-то API запрашивающий данные из внешней системы может предполагать, что в определенных обстоятельствах нужно обязательно сделать какие-то дополнительные действия. Как ему гарантированно донести до программиста эту необходимость? Checked exceptions эту проблему решают. Пусть плохо, пусть не удобно, но всё же часто лучше что-то, чем ничего.
Вот же ж козлы. В жизни не поверю, что несколько инженеров тайком могли сделать подобное. И бесмыссленно, и неэтично, и противозаконно. Другое дело, если сверху пришел приказ сделать любой ценой — вот такое выглядит намного правдоподобнее.
Эх, еще бы в язык, в котором бы можно было делать именованные синонимы ко встроенным типам либо как-то еще передавать контракты — цены бы ему не было.
Пример:
Пусть у книги есть номер ISBN. Это строка определенной длины и в определенном формате, т.е. есть определенный контракт на то, какие значения являются допустимыми. В большинстве языков у нас есть слудующие варианты:
1)
В объекте «книга» делаем поле isbn типа String, а то, что этот тип особенный — держим в уме (что, естственно, плохо). Там где ожидается передача ISBN — передаем строку (и не имеем гарантий, что туда не подсунут что-то левое).
class Book { String isbn; }
2) Делаем тип IsbnType, который внутри содержит поле stringValue типа String. В объекте «книга» делаем поле isbn типа IsbnType. Проблемы: мы не можем непосредственно к IsbnType применять строковые операции, а также, что хуже, такое решение обычно намного более тяжеловесное — ведь у нас IsbnType самостоятельный объект.
class IsbnType { String value; }
class Book { IsbnType isbn; }
3) Делаем тип IsbnType, который расширяет тип String. В объекте «книга» делаем поле isbn типа IsbnType. Основная проблема — во многих языках возможности расширять стандартные типы просто нет; а там где есть — это выключает для «расширеных» типов многие оптимизации. А ведь нам-то всего-лишь хотелось разделить произвольные строки и ISBN…
class IsbnType extends String;
class Book { IsbnType isbn; }
«Предсказывать» — вполне подхоядщий стандартный термин, когда речь идет о построении математической модели зависимости одного (неизвестного) параметра от других. То, что пользователи знают свой доход в данном контексте значениям не имеет.
Демо
Я про то, что querySelector всегда мэтчит от корня (документа), а не от указанного контектса. И обычно это НЕ то, что нужно.
Пожалуй, основная проблема — тематика уж очень далека от основной аудитории Хабра.
Просмотрел бегло актуальные доки — судя по всему, со времен отделения c3p0 от самого Hibernate, hibernate.connection.pool_size со значением 0 именно отключает встроенный пул и вроде бы действительно отключает все дополнительные механизмы, нужные для пуллинга.
Второй пример — вообще смешно. Вы выделили жирным «then»часть предложения, но почему-то не «if» :)
Ваш случай подпадал под один вариант, а вы выбрали другой. И пишете, что документация плохая :)
PS; Вместо того, чтобы использовать коннекшн пул нулевого размера — может лучше его всё же полностью убрать? :)
PS2: Статью следовало бы назвать «Даже усли использовать хорошие библиотеки, вы всё равно можете выстрелить себе в ногу» :)
Почему 3 первых обработчика не объединены в один? Ах, код ошибки разный! Но ведь определение кода ошибки как и построение ответов для ошибок 4xx можно вынести в отдельный метод. Точно так же как мы поступаем с любым дублирующимся кодом. Почему на catch блоки нельзя распространить обычные практики?
Хороший повод познакомиться с D поближе )
Пример:
Пусть у книги есть номер ISBN. Это строка определенной длины и в определенном формате, т.е. есть определенный контракт на то, какие значения являются допустимыми. В большинстве языков у нас есть слудующие варианты:
1)
В объекте «книга» делаем поле isbn типа String, а то, что этот тип особенный — держим в уме (что, естственно, плохо). Там где ожидается передача ISBN — передаем строку (и не имеем гарантий, что туда не подсунут что-то левое).
2) Делаем тип IsbnType, который внутри содержит поле stringValue типа String. В объекте «книга» делаем поле isbn типа IsbnType. Проблемы: мы не можем непосредственно к IsbnType применять строковые операции, а также, что хуже, такое решение обычно намного более тяжеловесное — ведь у нас IsbnType самостоятельный объект.
3) Делаем тип IsbnType, который расширяет тип String. В объекте «книга» делаем поле isbn типа IsbnType. Основная проблема — во многих языках возможности расширять стандартные типы просто нет; а там где есть — это выключает для «расширеных» типов многие оптимизации. А ведь нам-то всего-лишь хотелось разделить произвольные строки и ISBN…