Вы кажется не разобрались, как в IDE настроить авто импорт.
Там же не надо разбираться, он же есть из коробки. Правда надо спозиционироаться на строке в которой класс без импорта и нажать Alt + Enter. А потом выбрать, какой конкретно класс надо импортировать.
А зачем простите коммментировать код, чтобы понять как программа себя ведет без него?
А есть ещё какой-то другой способ узнать как программа ведёт себя без этого кода?
Это какой-то частный случай дебага?
Ну да. Обычно при прогоне юнит тестов таким занимаешься. Но бывает что и в разработке, хоть и редко
Ага, закомментировал строчку, образовался неиспользуемый импорт. Сначала удали импорт, потом пробуй запустить код, чтобы посмотреть, что будет без этой строки. Потом раскомментируй строку и верни обратно импорт. Воркфлоу моей мечты )))
У меня такой же ноут, только кажется gen2, тоже для работы. Очень утомляет шум вентиляторов, работают, такое впечатление что постоянно. У вас нет такого?
Мапа в которой лежат объекты из статьи имеет сложность операции get O(n).
Тут несколько пунктов
Вы наглядно показали, почему не надо использовать энтити в качестве ключей мапы. Если есть какой-то код в котором энтити используются как ключи мапы, то почти всегда там можно и нужно в качестве ключей использовать не сами энтити, а их Id.
Правда, есть один случай, когда разработчик вынужден использовать Entity как ключи мапы - это HashSet у которого под капотом HashMap. Я говорю о случае, когда на стороне many у one-to-many в hibenate тип коллекции - Set. По моему мнению, такого лучше избегать и использовать List.
А если разработчик всё-таки хочет использовать Set, то в случае связей один ко многим это не создаюёт проблем. Прежде всего, обычно разработчик просто перебирает все элементы коллекции и квадратичной сложности не возникает. А ещё сторона many в маппинге one-to-many не должна содержать много элементов. Если элементов много, то лучше эту связь не мапить. Поэтому вред от O(n) на добавление нового элемента относительно небольшой.
А какой сакральный смысл постоянно работать с такой маленькой диагональю?
Я работаю на 15 дюймовым ноутом, потому что часто работаю из разных мест. Привык и как-то нормально уже. Думаю за 13 точно также люди постепенно перелезают, чтобы таскать легче было. Может помогает то, что я начинал с ЭЛТ мониторов с 13 дюмовой диагональю. Но врядли, я те времена давно забыл
Посмотрите как, якобы для безопасности, по диску непрерывно шастают фоновые процессы, причём так, что если это не SSD, то комп встаёт колом.
Не знаю, зачем они это делают, но я сильно от этого пострадал. Отключал что находил, но после какого-то обновления поведение возвращалось. Очень бесит. Больше всего бесит, что виндоус периодически начинает зачем-то лезть в сеть и кажется не с обновлением, а с чём-то ещё. А у меня тут тормозной восьмимегабитный ADSL . И получается, что если компьютер оставить наедине, то он смотреть что-нибудь через интеренет с других устройств будет вообще невозможно
В "правильном" ответе на 7-ой вопрос в Антарктиде группировка не под дате, а по типу
Там есть вариант, где в селекте первым стоит date и два варианта, где первым стоит type. Понятно, что варианты с первым type не могут быть верными вообще никак, потому что в результате в первой колонке дата. И, конечно, по тесту результат с date в селекте неверный ))
Мне просто досадно, что я трачу по полтора часа на очередное обсуждение "Top 50 Java questions you should know"
Потенциальные работадатели, наверное, тоже переживают, что в очередной раз потратили полтора часа на чтобы подсказать интересные вопросы кандидату, который не собирался у них работать. Баланс ))
Похоже дело в ваших догадках, "чтении" моих мыслей, да прочтении между строчек!
Да, дело в этом. Я совершенно неправильно истолковал ваш текст.
Поэтому хочу спросить, что вы хотели подчеркнуть, когда написали, что получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных?
Что благодаря разбиению на страницы можно загружать только часть данных и не нужно ждать пока прогрузится вся таблица? И что благодаря сортировке можно посмотреть не только первые страницы, но и последние.
И таким образом, благодаря этим приёмам получилось отображать данные больших таблиц? Потому то без постраничной загрузки это невозможно?
Я тут тоже высказываю догадки и занимаюсь прочтением между строк, это неправильно. Напишите, пожалуйста, что вы хотели сказать.
И что вы имели в виду под грамотной работой с базой данных? Какие приёмы из статьи?
Укажите где я говорил, что произвольные сортировки с миллионными офсетами работают с приемлемой скоростью?
Ну вы же написали, что получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных. Наверное вы бы не стали уточнять, что речь идёт о таблицах на сотни гигабайт, если бы скорость работы с ними была неприемлемой. Наверное вы не стали бы говорить про возможность сортировки, если бы с ней были какие-то проблемы.
Есть и страница 1011, под спойлером "Работает!" в ответе вам. С таймингами в отладчике firefox.
Да, странно, что номер страницы 1011, а offset - 352 . Поэтому я и уточняю. Наверное отладчик firefox показывает загрузку какой-то другой страницы? Но вот то, что строки по одной загружаются я правильно понял?
Это же открытый код.
Я чего-то ссылки в статье не нахожу. Плохо ищу?
Вдруг есть идея как сделать так, чтобы выдавало за 1-2мс на произвольной сортировке и базе
Если сделать индексы по каждой колонке, сортировать только по одной колонке, не накладывать фильтры и убрать limit ... offset , то можно . А так - я не знаю как. Вот прочитал что вы написали про большие таблицы, посмотрел на возможность сортировки в интерфейсах и подумал - вдруг вы знаете.
В простом случае да [используется limit ... offset ] .
Судя по коду у вас как раз такой случай. И я вас так понял, что всё работает с приемлемой скоростью. Или я неправильно понял?
Если хочется быстрее, то конечно надо переходить на ctid
А можно использовать ctid вместе с сортировкой по произвольной колонке?
Первичный ключ и гео столбцы [по ним есть индексы]
На скриншоте можно сортировать по любой колонке. Скорость получается приемлемой несмотря на отсутствие индексов?
И ещё на скриншоте оффсеты совсем маленькие. 352, например. И они меняются на единицу каждый раз. Такое впечатление, что каждая строка загружается отдельным запросом с limit... offset . Страницы из середины или конца больших таблиц при этом загружаются быстро?
Получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных.
А как вам это удалось? Ведь судя по джаваскрипту используется конструкция limit ... offset . Неужели работает? Или там одна строка занимает мегабайты? Но на скриншоте строки маленькие.
Интересно, узнать объём данных поточнее. Сколько там сотен гигабайт получилось? И сколько это строк. И на каком диске лежат данные?
А что такое фиксация?
Там же не надо разбираться, он же есть из коробки. Правда надо спозиционироаться на строке в которой класс без импорта и нажать Alt + Enter. А потом выбрать, какой конкретно класс надо импортировать.
А есть ещё какой-то другой способ узнать как программа ведёт себя без этого кода?
Ну да. Обычно при прогоне юнит тестов таким занимаешься. Но бывает что и в разработке, хоть и редко
Ага, закомментировал строчку, образовался неиспользуемый импорт. Сначала удали импорт, потом пробуй запустить код, чтобы посмотреть, что будет без этой строки. Потом раскомментируй строку и верни обратно импорт. Воркфлоу моей мечты )))
У меня такой же ноут, только кажется gen2, тоже для работы. Очень утомляет шум вентиляторов, работают, такое впечатление что постоянно. У вас нет такого?
Тут несколько пунктов
Вы наглядно показали, почему не надо использовать энтити в качестве ключей мапы. Если есть какой-то код в котором энтити используются как ключи мапы, то почти всегда там можно и нужно в качестве ключей использовать не сами энтити, а их Id.
Правда, есть один случай, когда разработчик вынужден использовать Entity как ключи мапы - это HashSet у которого под капотом HashMap. Я говорю о случае, когда на стороне many у one-to-many в hibenate тип коллекции - Set. По моему мнению, такого лучше избегать и использовать List.
А если разработчик всё-таки хочет использовать Set, то в случае связей один ко многим это не создаюёт проблем. Прежде всего, обычно разработчик просто перебирает все элементы коллекции и квадратичной сложности не возникает. А ещё сторона many в маппинге one-to-many не должна содержать много элементов. Если элементов много, то лучше эту связь не мапить. Поэтому вред от O(n) на добавление нового элемента относительно небольшой.
У меня наоборот, винда батарейку высаживает дольше. Вы что-нибудь делали для настройки энергопотребления а Линуксе?
Я работаю на 15 дюймовым ноутом, потому что часто работаю из разных мест. Привык и как-то нормально уже. Думаю за 13 точно также люди постепенно перелезают, чтобы таскать легче было. Может помогает то, что я начинал с ЭЛТ мониторов с 13 дюмовой диагональю. Но врядли, я те времена давно забыл
Не знаю, зачем они это делают, но я сильно от этого пострадал. Отключал что находил, но после какого-то обновления поведение возвращалось. Очень бесит. Больше всего бесит, что виндоус периодически начинает зачем-то лезть в сеть и кажется не с обновлением, а с чём-то ещё. А у меня тут тормозной восьмимегабитный ADSL . И получается, что если компьютер оставить наедине, то он смотреть что-нибудь через интеренет с других устройств будет вообще невозможно
А как вы с этим боретесь? Как выбираете чем заниматься и что говорите тем, чьи задачи делать не будете?
А есть где-нибудь сравнение библиотеки с аналогичными решениями. Я обычно easy random использую, есть ещё куча других по моему
А я вот не могу. В седьмом вопросе правильного ответа на самом деле нет, в восьмом первые три ответа одинаковые, просто ткнул наугад
Там есть вариант, где в селекте первым стоит date и два варианта, где первым стоит type. Понятно, что варианты с первым type не могут быть верными вообще никак, потому что в результате в первой колонке дата. И, конечно, по тесту результат с date в селекте неверный ))
Собственно об этом и был вопрос ))
А зачем оставлять удалённых пользователей в той же таблице, в которой хранятся активные? В чём смысл? Почему их не копировать в отдельную таблицу?
Потенциальные работадатели, наверное, тоже переживают, что в очередной раз потратили полтора часа на чтобы подсказать интересные вопросы кандидату, который не собирался у них работать. Баланс ))
Да, дело в этом. Я совершенно неправильно истолковал ваш текст.
Поэтому хочу спросить, что вы хотели подчеркнуть, когда написали, что получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных?
Что благодаря разбиению на страницы можно загружать только часть данных и не нужно ждать пока прогрузится вся таблица? И что благодаря сортировке можно посмотреть не только первые страницы, но и последние.
И таким образом, благодаря этим приёмам получилось отображать данные больших таблиц? Потому то без постраничной загрузки это невозможно?
Я тут тоже высказываю догадки и занимаюсь прочтением между строк, это неправильно. Напишите, пожалуйста, что вы хотели сказать.
И что вы имели в виду под грамотной работой с базой данных? Какие приёмы из статьи?
Ну вы же написали, что получается отображать данные таблиц на сотни гигабайт с помощью постраничной загрузки с возможностью сортировки в базе данных. Наверное вы бы не стали уточнять, что речь идёт о таблицах на сотни гигабайт, если бы скорость работы с ними была неприемлемой. Наверное вы не стали бы говорить про возможность сортировки, если бы с ней были какие-то проблемы.
Да, странно, что номер страницы 1011, а offset - 352 . Поэтому я и уточняю. Наверное отладчик firefox показывает загрузку какой-то другой страницы? Но вот то, что строки по одной загружаются я правильно понял?
Я чего-то ссылки в статье не нахожу. Плохо ищу?
Если сделать индексы по каждой колонке, сортировать только по одной колонке, не накладывать фильтры и убрать limit ... offset , то можно . А так - я не знаю как. Вот прочитал что вы написали про большие таблицы, посмотрел на возможность сортировки в интерфейсах и подумал - вдруг вы знаете.
Это ж будет баг в реализации sql. Я не слышал про СУБД с таким поведением. Они правда есть или это предположение?
В смысле пользы от разбиения на секции раз не очень удачный пример. Если бы секций не было, сканирование по индексу прошло бы быстрее.
Судя по коду у вас как раз такой случай. И я вас так понял, что всё работает с приемлемой скоростью. Или я неправильно понял?
А можно использовать ctid вместе с сортировкой по произвольной колонке?
На скриншоте можно сортировать по любой колонке. Скорость получается приемлемой несмотря на отсутствие индексов?
И ещё на скриншоте оффсеты совсем маленькие. 352, например. И они меняются на единицу каждый раз. Такое впечатление, что каждая строка загружается отдельным запросом с limit... offset . Страницы из середины или конца больших таблиц при этом загружаются быстро?
А как вам это удалось? Ведь судя по джаваскрипту используется конструкция limit ... offset . Неужели работает? Или там одна строка занимает мегабайты? Но на скриншоте строки маленькие.
Интересно, узнать объём данных поточнее. Сколько там сотен гигабайт получилось? И сколько это строк. И на каком диске лежат данные?
Индексы, наверное, по всем колонкам, да?