как можно передавать айди, которого нет в бд?

теоретически где-то проебать session.save(pojик) теоретически передать вместо одного id мифический другой ( many bar to one foo, по bar получать foo и вместо fooid отдать barid) иногда ты можешь получать айди снаружи из чужого треда а другой чужой тред уже его удалил но это примеры из серии "надо больше спать"

привет всем. повторяю тут знания по Java. скажите ведь если я создам переменную так Integer x = new Integer(100); то она уже будет храниться не в стеке а в куче ? или все равно в стэке ?

Именно этот инт будет в кэше интов. Но он всё равно в хипе.

теоретически где-то проебать session.save(pojик) теоретически передать вместо одного id мифический другой ( many bar to one foo, по bar получать foo и вместо fooid отдать barid) иногда ты можешь получать айди снаружи из чужого треда а другой чужой тред уже его удалил но это примеры из серии "надо больше спать"

ну первые случаи как правило относятся к необрабатываемым и поэтому тот же темплэйт кидает рантайм

а что касается тредов, то есть такая штука, как блокировки, поэтому тоже мимо

Два пользователя одновременно работают, один удалил запись, второй в этот момент попытался её открыть

Как ты это будешь разруливать блокировками

Single user?)

Два пользователя одновременно работают, один удалил запись, второй в этот момент попытался её открыть

обычные блокировки на базе транзакциями

на таблице, на строчке (на записи)

и снова берял снял с языка

твой кейс на уровне базы разруливается

Тут разговор про то, откуда может взяться ид которого нет в БД

Я не про персистетность данных сказал

А про невалилный ид

по поводу айди и блокировать, я имел в виду синхронизированный доступ

чтобы не возникла ситуация, когда обращаешься к тому, что снесли

Ну в любом случае, ид то не корректный уже

Ну, это как-то не особо user-friendly блокировать запись, а тем более таблицу на время работы с ней

но ты согласен, что такие кейсы сразу рассматривают, как проблемные и их решают?

точнее предотвращают

Ну, это как-то не особо user-friendly блокировать запись, а тем более таблицу на время работы с ней

это вообще по умолчанию в бд, по крайней мере так у меня было с ораклом и постгресом

Нет, это не проблема

неблокирующее только селекты

Типичный кейс в многопользовательском приложение

Так там про селект и разговор?)

Типичный кейс в многопользовательском приложение

на некорректный ид, если что сработает рантайм эксепшен, прям внутри темплэйта

что-то свое городить не имеет смысла

Ну я не говорю что надо что то городить

так уже сгородили???

http://www.linux.org.ru/news/java/12829927

Punk,l,? ., ;

меня тимлид выебал за optional.get() в коде

правильно сделал?

особенно интересно мнение товарища @guga4ka

http://royvanrijn.com/blog/2016/04/deprecating-optional-get/

это я читал, и тимлиду показывал, причина частично в этом

это я читал, и тимлиду показывал, причина частично в этом

А другая причина в чём?)

А это я хочу гугочку потеребить, мне кажется он подскажет

уверен, что он компетентен в этом случае

Все просто. Для чего бы юзал Optional? Правильно, ты заранее подумал о том, что у тебя операция может не возвращать значение и предупредил пользователя апи, мол смотрит, чувак, тут может не быть данных, будь добрый, помни о этом. А что делает Optional.get когда твой Optional none? Бросает эксепшен, насколько я помню джаву. Ты обрабатываешь этот случай?

Если в двух словах, то это не канонничный способ работы с монадой Optional. Канонничных способов тут несколько. Если тебе нужно получить значение, которое лежит внутри, используй orElse и явно задай дефолтное значение.

Или если тебе нужно отображение данных на функцию, используй map

Если у тебя есть вложенность тогда юзай flatten а потом map

Во, Гуга молодца, слово в слово тимлида повторил

Во, Гуга молодца, слово в слово тимлида повторил

Лол, что это за проверка меня? ?

просто что ты, что он — скалоебы, а оно все оттуда идет

Разве гет дает ошибку на пустое значение?

Optional.of() дает

А не гет

гет другой эксепшн кидает

NoSuchElementException

https://habrahabr.ru/company/jugru/blog/307180/

Всем привет. Сегодня столкнулся с таким багом: public User(String username, String country) {...} // ... User u = new User(country, name); // аргументы перепутаны Его можно было бы избежать, если бы у имён пользователей и стран был свой класс, т.е.: public User(Username name, Country country) {...} Но стоит ли так делать и в каких случаях?

u.setCountry()

Всем привет. Сегодня столкнулся с таким багом: public User(String username, String country) {...} // ... User u = new User(country, name); // аргументы перепутаны Его можно было бы избежать, если бы у имён пользователей и стран был свой класс, т.е.: public User(Username name, Country country) {...} Но стоит ли так делать и в каких случаях?

не стоит городить объектов ради 1 проперти

u.setCountry()

А что это даст? Вероятность той же самой ошибки всё равно остаётся: u.setCountry(name); u.setName(country);

Нужно быть неадекватным, чтобы напечатать сеткантри(юзернейм)

Всем привет. Сегодня столкнулся с таким багом: public User(String username, String country) {...} // ... User u = new User(country, name); // аргументы перепутаны Его можно было бы избежать, если бы у имён пользователей и стран был свой класс, т.е.: public User(Username name, Country country) {...} Но стоит ли так делать и в каких случаях?

Хороший наброс, в java нету именованных параметров. Так что тебе либо в kotlin, scala и возможно groovy, вот честно не помню есть ли в последнем они, либо следить за тем что ты делаешь.

Нужно быть неадекватным, чтобы напечатать сеткантри(юзернейм)

да тут вопрос скорее про конструктор

Всем привет. Сегодня столкнулся с таким багом: public User(String username, String country) {...} // ... User u = new User(country, name); // аргументы перепутаны Его можно было бы избежать, если бы у имён пользователей и стран был свой класс, т.е.: public User(Username name, Country country) {...} Но стоит ли так делать и в каких случаях?

можно воспользоваться паттерном builder

Всем привет. Сегодня столкнулся с таким багом: public User(String username, String country) {...} // ... User u = new User(country, name); // аргументы перепутаны Его можно было бы избежать, если бы у имён пользователей и стран был свой класс, т.е.: public User(Username name, Country country) {...} Но стоит ли так делать и в каких случаях?

ради того чтобы избежать опечатки - ни в коем случае.

Нет, вопрос не только про конструктор, а вообще про вызов функции с параметрами с одинаковыми типами: void doSomething(String name, String country, String email)

Вот в Go можно так без оверхеда: type Username string В Scala, насколько я понял, есть такая же возможность.

ERROR: S client not available

Нет, вопрос не только про конструктор, а вообще про вызов функции с параметрами с одинаковыми типами: void doSomething(String name, String country, String email)

https://kotlinlang.org/docs/reference/functions.html#named-arguments http://docs.scala-lang.org/tutorials/tour/named-parameters.html В груви такого нету, как и в джаве. Если тебе так уж это нужно, юзай билдеры http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html

дефолтных значений у параметров тоже нету.

Именованные параметры и дефолтные значения - не то что я ищу. Потому что они не решают проблему: fun doStuff(name: String, country String) {...} doStuff(name = country, country = name) Опечататься становится труднее, но на это выражение компилятор ругаться не будет. Вот на примере Go (извините, что не на примере Scala - не разбираюсь в ней). Выражения type Username string type Country string объявляют новые типы, который точно такие же как строка, но компилятор будет ругаться, если их спутать между собой или строкой. Код для наглядности: https://play.golang.org/p/j9KLUNqKnz Я понял, что прямо так в Java нельзя. Но создавать класс для каждого типа параметра совсем не принято? Из-за оверхеда или по другой причине?

ебаный ждбстемплейт

ебаный ждбстемплейт

ну давай, рассказывай

ебаный ждбстемплейт

хуй проссышь как ему кинуть обычный запрос без парамов

речь о ждбс темплейте с неймед параметрами

ЛОЛ

jdbcTemplate.update(SQL_STRING, ImmutableMap.of());

вот так вот заебца

опять ты не хочешь гуглить?

namedParameterJdbcTemplate.getJdbcOperations().execute()

Именованные параметры и дефолтные значения - не то что я ищу. Потому что они не решают проблему: fun doStuff(name: String, country String) {...} doStuff(name = country, country = name) Опечататься становится труднее, но на это выражение компилятор ругаться не будет. Вот на примере Go (извините, что не на примере Scala - не разбираюсь в ней). Выражения type Username string type Country string объявляют новые типы, который точно такие же как строка, но компилятор будет ругаться, если их спутать между собой или строкой. Код для наглядности: https://play.golang.org/p/j9KLUNqKnz Я понял, что прямо так в Java нельзя. Но создавать класс для каждого типа параметра совсем не принято? Из-за оверхеда или по другой причине?

Если тебе нужна проверка компилятором, тогда да, заводить новый тип на каждый параметр. Но мне кажется, это не верный путь, у нас так не принято.

развве не ебаный метод?

http://forum.spring.io/forum/spring-projects/data/21714-using-namedparameterjdbctemplate-with-no-params

подтверждение моих слов

спасибо, но такой способ конечно немного уебанский

хоть и работает

норм ты ща разрабов спринга обоссал

ну да ладно

Если тебе нужна проверка компилятором, тогда да, заводить новый тип на каждый параметр. Но мне кажется, это не верный путь, у нас так не принято.

Большого оверхеда не будет, но пользоваться твои апи будет очень не удобно, что бы на джаве мимально провернуть это, нужно сделать так. public class Temp { public static void main(String[] args) { new User(new Name("name"), new Country("country")); } } class Name{ final String name; public Name(String name) { this.name = name; } } class Country{ final String country; public Country(String country) { this.country = country; } } class User{ final Name name; final Country country; public User(Name name, Country country) { this.name = name; this.country = country; } }

как вы так код вставляете?

Но так никто не делает, всё стараются закрыть поля и сделать их приватными, сделать один консткрутор без аргументо и сделать getter & setter

вот так

``` ```

` `

hjhj

а почему красного цвета шрифт

?

Но так никто не делает, всё стараются закрыть поля и сделать их приватными, сделать один консткрутор без аргументо и сделать getter & setter

Это в случае конструктора. А в случае функции с большим количеством переменных одинаково типа? Для каждой такой функции заводить свой класс с нужными полями?

Это в случае конструктора. А в случае функции с большим количеством переменных одинаково типа? Для каждой такой функции заводить свой класс с нужными полями?

Да, но снова же, так никто не делает.

потому что полный код будет пиглядет не читаемо. public class Temp { public static void main(String[] args) { Name name = new Name(); name.setName("name"); Country country = new Country(); country.setCountry("country"); User user = new User(); user.setName(name); user.setCountry(country); } } class Name { private String name; public Name() { } public String getName() { return name; } public void setName(String name) { this.name = name; } } class Country { private String country; public Country() { } public String getCountry() { return country; } public void setCountry(String country) { this.country = country; } } class User { private Name name; private Country country; public User() { } public Name getName() { return name; } public void setName(Name name) { this.name = name; } public Country getCountry() { return country; } public void setCountry(Country country) { this.country = country; } }