Не требуется, но это бесплатная гарантия на уровне бд. Так еще и ускоряет и упрощает дампы потом. Так-то много где и что можно отдельно гарантировать, на уровне CI код проверять и прочее. Но зачем?
Меня вот все минусуют, но я вижу в ответ только спорные высказывания типа "плюсы - не плюсы", а не проблемы и конструктив. И тихие нажатия на кнопочку "-rep". Собственно, говорит многое о уровне несогласных)
Тут даже из названия очевидно, что object relational mapping не про хранимки на 5 экранов
Смешались в кучу кони, люди...
С чего вы взяли, что там хранимки на 5 экранов? Это 5 экранов чистого SQL, хранимки вообще отдельно. Мне казалось, это очевидно из сообщения
Очевидно что bulk вставки в БД быстрее сингл инсертов, да еще и с проверкой вложенных объектов? Что вы хотите доказать?
И вот опять. Можно ткнуть пальцем, где было хоть слово про сингл инсерты?
Наоборот, я явно указал, что оптимизировал как только можно. Там был батчинг хибернейта настроен, плюс опытным путем было выяснено, что сами листы с объектами лучше тоже бить на пачки, а не пихать разом. Потому что хибернейт-то их разобьет на пакеты нужного размера, но вот кэши у него при этом перегреются это всё держать
но если писать так, как надо писать, то скорость отличается процентов на 20, а не в 4 раза.
А если отвечать на то, что писали, то можно узнать, что люди вокруг - не идиоты, которые наляпали кое-как и бегут жаловаться на хабр, а заранее оптимизировали всё и рассказывают итоговые результаты)
Да там даже с удобством проблемы. Они только-только пересели на стейбл версию Раста. И до сих пор вебсокеты, одна из основных фич любого бэкенда, отложены аж на 3 мажорные версии вперед. А автор рекомендует параллельно Rocket запускать просто второй сервер (сторонний, с поддержкой вебсокетов) и организовывать взаимодействие между ними, типа решение (что мешает просто изначально взять не Rocket, а то, где есть вебсокеты?). Есть большие вопросы к тому, кто рулит проектом и строит его роадмапу
Spring Data - это буквально 1 строчка в репозитории, объявляющая метод. Реализацию за вас сгенерирует сама спринг дата. И получается, что у нас репозиторий является интерфейсом, который просто содержит объявления нужных нам методов с парой анноташек (реально 0-2 на метод). А дальше всё, только дергаем эти методы. Реализовывать, писать какие-то бины для настройки и творить прочий бойлерплейт не надо. Пагинация, круд и прочее из коробки
Сама генерация реализации происходит одним из трех способов. Или по имени метода (типа findByIdAndNameOrderByName, он сам парсит имя и понимает, что хотим), или по jpql/hql в анноташке Query, или по голому sql в той же самой анноташке
Транзакции делаются одной аннотацией, остальные фичи бд не сильно сложнее. Глубина выборки регулируется EntityGraph и тд. Много всего
Лично я как-то пытался в шарп вкатиться, даже дважды. Как-никак один из мажорных языков, по сути единственный неощупанный у меня. Но каждый раз я натыкался на локальные приколы шарпа (падение перфоманса в 20 раз из-за перестановки 3 множителей в выражении из-за кривого инлайна, любовь разрабов пихать кучу логики в проперти, из-за чего приходится гадать, безопасно ли обращаться в цикле к ним, и тд) и его экосистемы (тот же десктоп - просто мрак и ужас. Куча технологий, и все или заброшены, или в превью, и весь этот монстр Франкенштейна куда-то движется. Winforms, Xamarin, WPF, WinUI, UWP, MAUI... столько всякой хрени, а использовать нечего. Редакторы нормально поддерживают только Winforms и WPF, которые давно заброшены и устарели. WinUI и UWP только появились и сразу сдохли, MAUI вообще до сих пор в превью, но должен заменить в очередной раз все остальное....)
В общем, не сложилось у меня с шарпом и его чехардой)
Для себя выбрал Джаву (на которой и работаю), Котлин (который просто очень вкусный для кроссплатформерной клиентской разработки), Тайпскрипт (веб фронтенд, но в перспективе, когда допилят, мб получится заменить Котлином) и Раст (недавно ознакомился, просто влюбился в язык. Оставил его вместо плюсов для системщины, хочу заодно попробовать сделать бэк на нем, чтобы сравнить в этом с Джавой)
На Расте у меня это будет первый проект по сути, поэтому тоже все только в будущем. Долго выбирал между Actix и Rocket, остановился на первом в итоге. Не понравилось отношение разработчиков Rocket к проекту и полный провал по перфомансу по сравнению с конкурентом. А у Actix из коробки интеграция с Diesel, вот на него выбор и распространился, т.к. альтернатив, по сути, и нет
Это "мир очень плохих библиотек в джава" по сути еще и лишь по вине автора, который выбрал голый Hibernate и по ходу статьи пытался изобрести кривой аналог Spring Data JPA
Собственно, если посмотреть на Spring Data (которым пользуется большинство в джава-мире), то сразу видно, что там все гораздо стройнее и красивее. И пишется лучше, и самим запросы писать можно, и абстракции на любой вкус, и транзакции декларативные, и генерация запросов по имени метода, и еще куча фич. Вообще красота, буквально 1 строчкой любой запрос делается, 0 бойлерплейта
Лично я все равно предпочитаю Spring Data JDBC или JOOQ (и не люблю ORM в целом), но просто глаза режет от того, что каждый второй пишет про EF, приводя в плюсы то, что есть и в самом используемой библиотеке джавы для бд, просто автор этого, видимо, не знал, или не хотел показывать)
Возможно. У меня другие платформы встречаются только в петах, а там ORM я не использую
Через месяц дойдут руки запилить бэк к пету на Rust, там хочу потыкать хваленую кодогенерацию времени компиляции ORM Diesel, посмотрю на их реализацию
Но в целом, и из хибернейта можно выжать приемлемый SQL, почти всегда. Но зачастую это потребует такой возни с конфигами и жонглирования аннотациями, что десять раз бы уже успел руками написать этот запрос нормально и пойти дальше. И даже в таких случаях результат все равно в 3-5 раз медленнее голого jdbc (у меня получалось в лучшем случае 43с jdbc vs 4,5 минуты hibernate на большом инсерте вложенных объектов в бд)
Плюс, если бы все было так локально, то и поливали грязью бы только хибер, а не все ORM в целом. Я почему-то уверен, что если копнуть поглубже, то и в EF найдутся проблемы
Вот у меня прошлый проект был тем самым кровавым энтерпрайзом. С лютым легаси и тд. И вот там бд была оракл, на 200 000 таблиц и 80 000 хранимых процедур. Запросы писались руками и занимали 5-8 экранов сплошного текста. Я бы скорее сдох от старости, чем заставил бы ORM сгенерировать хоть что-то рабочее на таком объеме данных. И что-то мне подсказывает, что ORM тут могла быть любая, ничего от этого не изменилось бы
Я уже молчу про хинты запросов для планировщика, которые есть в Оракле и, с экстеншеном, в Постгрессе. Что-то я сомневаюсь, что тут тоже можно сгенерировать что-то адекватное по сравнению с тем, что знающий проект человек напишет ручками
Любая известная мне IDE от Jetbrains замечательно с этим справлялась с помощью подсказок. Пишешь имя первого поля, она подсказывает остальные. И дает два варианта - с id и без, для инсерта
Я сейчас работаю на проекте с 2млн строк кода и Hibernate. Насмотрелся на эти гирлянды на всю жизнь. И знаете, когда разница времени выполнения между запросом от хибера и ручным составляет 700 раз, немного задумываешься
Собственно, многие люди и тут, и в крупных компаниях солидарны с моим отношением к ОРМ (достаточно посмотреть на начало этого треда)
Но для фанатиков всегда "не любит мое любимое = ниасилил"
Тогда тем более лучше разделять по бд их. Потому что на таком объеме вы не перегрузите его количеством коннекшенов, но при этом обеспечите 100% изоляцию разных сервисов, просто не давая возможности на уровне бд влезть в соседнюю схему
А давно она проприетарная? Openjdk передает привет. Собственно ей массово и пользуются
А лучше настоящей кроссплатформерностью, гораздо лучшей и стабильной экосистемой и тем, что почему-то именно шарп копирует фичи из джавы, а не наоборот)
Плюс с нее легко уйти в котлин, который подмял под себя весь Андроид и точит зубы на кроссплатформу (десктоп и айос на нем уже достойные)
Был еще один, более актуальный (около 1к схем, а не 10-20к) тред на StackOverflow, но не могу его найти. Там у человека pg_dump вообще крашился
Общая суть в том, что при дампе такой большой бд pg_dump должен развесить кучу локов и все проверить, что очень сильно замедляет процесс (вплоть до невозможности делать это ежедневно) или вообще приводит к его падению
Возможно, в более новых версиях это пофиксили, не проверял (у нас не настолько много сервисов)
Использование отдельных бд требует отдельного коннекшена к каждой, что тоже может стать проблемой. По сути выбор между проблемами с бэкапами или проблемами с коннекшенами
Но в случае отдельных бд мы полностью исключаем использование чужих данных из других схем
PostgreSQL нужно создать разные схемы в рамках одного database
Не нужно. Постгря плохо переживает большое количество схем в одной бд. А вот большое количество самих бд - спокойно. Поэтому лучше сразу делать по отдельной бд для каждого сервиса с одной схемой в каждой
Проекты нужны делать сейчас, а пока созреет котлин, никто ждать не будет. Как выйдет в стейбл, тогда и стоит поднимать вопрос на чём лучше делать новый проект.
Все самое нужное уже в стейбле. Дальше уже QoL фичи идут
Я тут еще об одном нюансе подумал. Веб в котлине превращается в старое-доброе SPA. А веб на флаттере превращается в огромный канвас на всю страницу, на котором уже рисуется все, что надо.
И если SPA тот же гугл уже давно индексирует, то насчет канваса я очень сильно не уверен. Чую огромные, возможно даже нерешаемые проблемы с SEO еще
Я не призываю все бросать и бежать переучиваться. Просто рекомендую ознакомиться людям с альтернативой, которая имхо выглядит вкуснее. Может кому-то понравится больше и он откроет для себя что-то новое и приятное)
Там в конце два проекта на гитхабе с мультиплатформой. Вот в них есть модуль jvm, который билдит приложение с композом в бинарники под любой из 3 десктопов (на самом деле внутри каждого бинаря минимальная жвм, но этого не видно).
А еще есть модуль macos отдельно, где на свифте пишут UI и собирают в фулл натив пол макось, без всяких жвм внутри. Вот никто не мешает повторить это и для других платформ
Так говорите это тому, кто это утверждает ниже. Ну и опять же, с моей колокольни (на флаттере не писал) - если фреймворк зависит от плагинов, то рано или поздно возникнет ситуация, когда нужного плагина нет, и приходится спускаться в натив. Это все уже проходили с Cordova и Ionic. То, что вам пока это не попадалось, не значит, что это не случается. Это архитектурные проблемы таких фреймворков
Я бы не назвал swift общепринятым языком, он намного сложнее дарта.
Он общепринят не по причине легкости. А по причине вендорлока от Эппла. Да, это хреново, но это факт. На свифте огромное количество разработчиков, потому что это единственный фулл натив на IOS, плюс там еще сбоку макось и айпадось стоят
Как показывает практика - нет.
То-то у меня Flutter Gallery - одно из немногих подлагивающих приложений на телефоне (POCO X3 Pro). А "прогрев шейдеров" стал уже притчей во языцех
Надо полагать, речь идёт про свифт.
Свифт привязан к экосистеме эппла. Он хотя бы там нужен много где. А дарт за пределами флаттера - мусор. Тем более после убийства Angular.Dart
Был бы у флаттера любой адекватный язык - я бы и слова не сказал. Но у нас тут очередной $mol, считающий себя настолько крутым, чтобы не сочетаться вообще ни с чем.
И тут сразу же возникают вопросы, ради чего это? Почему люди должны выбрать именно эту поделку и тратить свое время на максимально местячковый язык, а не на альтернативы? И внятного ответа я пока ни разу не получил
Что значит "только UI"? Это то что составляет 90% кода мобильного приложения? Я бы очень не хотел делать UI в xcode. Тем более различия в платформах они далеко не только в UI, Flutter это маскирует.
Флаттер точно так же требует писать 2+ UI, насколько я помню. Как минимум разные визуальные стили под андроид/айос. Плюс под десктоп совсем другая верстка нужна и под веб
Про платформы - это не только флаттер маскирует. Писать в xcode не требуется, достаточно его иметь. Идея или андроид студия позволяют цеплять его сдк и кодить в нормальных IDE
Очевидно они выберут фреймворк, где надо писать один раз, а не 3 раза
Было бы еще это правдой) Что про 1 раз, что про 3
Кроме того, я бы предложил все же опустить градус фанбойства и чутка подумать.
Вы серьезно считаете, что кто-то в здравом уме выберет изучение нового языка, нового фреймворка, и переписывание всей кодовой базы, вместо простого размазывания существующей логики на котлине с Андроида на остальные платформы, подключения ее к существующему UI и выбрасыванием аж 3, теперь уже лишних, кодовых баз, и 1 языка?
Это шутка что ли? Зачем нужен мобильный фреймворк, который не поддерживает ios???
Он поддерживает, и это таки не только мобильный, это кроссплатформа. А зачем нужен - я уже перечислил кучу плюсов, как для индивидуалов, так и для команд разработки
Не понимаю сути вброса, разработка в видовс ничуть не сложнее чем в linux
Попробуйте скомпилить редис в WSL. Или поменять дефолтную версию Джавы в системе. Или поставить Kubernetes для локальной разработки. Или почитайте доку Докера
Везде или через задницу, или вообще невозможно, или "можно, но советуем не трогать винду даже десятиметровой палкой" (краткий пересказ доки Докера)
Не сложнее. Просто половина вещей невозможна, а вторая половина или неудобнее, или лагучее, или нестабильнее)
Не может быть быстродействие в виртуальной машине выше чем на нативной системе
Может, из-за разницы в железе. Когда у вас в виртуалку прокинуто железо, которым даже не пахнет ни у одного из нативных маков, она, как ни странно, работает быстрее этих самых маков. Вопрос именно в прокидывании этого железа
Вы явно не запускали macos в виртуалке, иначе бы не писали такую ерунду. Я с этим намучался очень долго и пробовал все варианты. Впрочем допускаю что у вас стоит очень серьёзное железо на киловатт, тогда да
Не самый слабый пк, но и не рабочая станция, и уж тем более не сервер. Ставится в Kubuntu 20.04 спокойно в QEMU, работает тоже спокойно. Ставил себе Big Sur, обновил потом до Monterey
Не работает эта штука на лаптопах, видеовывод всё-равно идёт через интел. Здесь я могу ошибаться, но ситуация с PCI passthrough точно не такая радужная как вы пытаетесь здесь описать. Это то, что касается прямого проброса NVIDIA PCI в гостевую систему.
Ноутбуки тут страдают, да. Как и почти во всех остальных аспектах. Однако даже тут есть модели, где люди прокидывали всё
Я же говорю про нормальные пк. Более того, даже там надо заранее учитывать железо, например наличие нормальных настроек IOMMU в чипсете. При этих условиях оно спокойно прокидывается. Да, надо будет заморочиться разок. Зато потом прекрасно работает. Я свое железо подбирал с учетом этих нюансов с самого начала
К слову, любые карты Nvidia, начиная с 10-й серии, не поддерживаются в макоси полностью. Апи Metal просто не работает на них, а визуал макоси на этом построен. Поддерживаются только видюхи самого Эппла, встройки Интела и любые дискретки АМД, включая последние. Собственно в этом может быть ваша проблема, и поэтому ее нет у меня
Если вы не изучили тему, пытались натянуть сову на глобус заставить работать изначально несовместимую платформу и закономерно потерпели фиаско, это не значит, что это невозможно в принципе
Котлин, как я понимаю, не предоставляет кроссплатформенных визуальных библиотек, либо они очень сырые.
Советую еще раз перечитать мое сообщение). Предоставляет для всего в стейбле, кроме IOS. Для него вот как раз в анстейбле еще, пока надо свифт использовать
Ругаться на дарт и, при этом, писать, что кроме котлина надо будет ещё знать свифт и андроид звучит, по меньшей мере, абсурдно. Впрочем и ваше брезгливое отношение к дарту мне непонятно. Хотя всю жизни пишу на джаве, мне он зашёл неплохо.
Вы суть потеряли. Во-первых, уже ниже человек писал, что и на флаттере от нативных языков никуда не деться. И, главное, во-вторых, это именно что общепринятые языки нативной разработки, а не конь в своем вакууме, как Дарт.
Давайте посмотрим с точки зрения команды разработчиков. У вас была половина команды на Android с Котлином, половина на IOS со Свифтом, еще отдельная команда для веба на жс/тс и, возможно, десктоп на чем-то.
А теперь мы приходим и предлагаем им сделать мультиплатформу. И даем две опции:
Изучать новый язык, который больше нигде не нужен. Вместе с новым фреймворком. Сохраняя некое дублирование интерфейса, зависимость от плагинов и необходимость иногда спускаться до такого знакомого им натива
Взять уже известные команде, общепринятые языки (Котлин, Свифт, Жс/Тс), но писать теперь на них только UI, и то не везде нужно. А все остальное становится кроссплафтормерным, включая большую часть этого самого UI. И никакой зависимости от плагинов, они могут использовать привычные им библиотеки с натива и тд. При этом по сути и какого-то фреймворка для изучения тоже нет, просто существующую логику с Android растащить на все платформы с минимальными изменениями кода. А отдельный язык для десктопа можно вообще дропнуть, он больше не нужен
Как вы думаете, что они выберут?)
Флутер очень быстр, не медленее чем андроид. Единственная проблема это раздутое приложение.
Там как минимум отдельный движок и поток рендера поверх OpenGL/WebGL/Metal. Это уже медленнее, чем фулл натив. Да, скорее всего большинству не критично, но факт
Фреймворк продуманный, очень прост в освоении. Это реально как глоток свежего воздуха по сравнению даже с андроид разработкой (про ios - я вообще молчу)
Смотря про какую андроид разработку вы говорите. Android Jetpack в целом и Compose в частности кардинально все упростили там и сделали удобным. И тот же фронт в Композе кардинально от флаттера не отличается. Те же функции, описывающие UI, как и в Реакте
Что я особенно ценю - так это возможность разрабатывать в windows и проверять на десктопе а затем на андроиде. Для ios достаточно просто скомпилировать в виртуалке и почти наверняка оно будет работать идентично. Работа с xcode в виртуалке, да ещё со сфитом - это боль.
Полностью кроссплафтормерный UI, за бортом только веб и IOS, для которых придется дублировать его (временно, пока решение из анстейбла не выйдет). Точно так же запускается на десктопе, чтобы не мучать тот же AVD
Но от себя добавлю: я врагу не пожелаю разрабатывать под виндой. Линь, только линь. Тем более что там делаются те же самые виртуалки, но с возможностью прокинуть туда железо и обеспечить быстродействие выше, чем у нативных систем. Люди таким образом делают себе макос в виртуалках, который работает быстрее нативного (потому что железо у маков... meh). Ну и виртуалку с виндой для игр, если хочется. Называется VFIO, оно же PCI passthrough
Как вариант. Но по сути уже Compose в стейбле для всего, кроме IOS. А значит можно писать на нем для всего остального и на Swift для IOS, а потом просто избавиться от свифта, когда и туда завезут
Не требуется, но это бесплатная гарантия на уровне бд. Так еще и ускоряет и упрощает дампы потом. Так-то много где и что можно отдельно гарантировать, на уровне CI код проверять и прочее. Но зачем?
Меня вот все минусуют, но я вижу в ответ только спорные высказывания типа "плюсы - не плюсы", а не проблемы и конструктив. И тихие нажатия на кнопочку "-rep". Собственно, говорит многое о уровне несогласных)
Проблемы начинаются на слове "генерировать" в сочетании в фразой "запрос на 5 экранов"
Кроме того, опять напоминаю про хинты, которые я пока ни в одном выхлопе генератора не видел
Смешались в кучу кони, люди...
С чего вы взяли, что там хранимки на 5 экранов? Это 5 экранов чистого SQL, хранимки вообще отдельно. Мне казалось, это очевидно из сообщения
И вот опять. Можно ткнуть пальцем, где было хоть слово про сингл инсерты?
Наоборот, я явно указал, что оптимизировал как только можно. Там был батчинг хибернейта настроен, плюс опытным путем было выяснено, что сами листы с объектами лучше тоже бить на пачки, а не пихать разом. Потому что хибернейт-то их разобьет на пакеты нужного размера, но вот кэши у него при этом перегреются это всё держать
А если отвечать на то, что писали, то можно узнать, что люди вокруг - не идиоты, которые наляпали кое-как и бегут жаловаться на хабр, а заранее оптимизировали всё и рассказывают итоговые результаты)
Да там даже с удобством проблемы. Они только-только пересели на стейбл версию Раста. И до сих пор вебсокеты, одна из основных фич любого бэкенда, отложены аж на 3 мажорные версии вперед. А автор рекомендует параллельно Rocket запускать просто второй сервер (сторонний, с поддержкой вебсокетов) и организовывать взаимодействие между ними, типа решение (что мешает просто изначально взять не Rocket, а то, где есть вебсокеты?). Есть большие вопросы к тому, кто рулит проектом и строит его роадмапу
Хибернейт без спринга - да, мрак.
Spring Data - это буквально 1 строчка в репозитории, объявляющая метод. Реализацию за вас сгенерирует сама спринг дата. И получается, что у нас репозиторий является интерфейсом, который просто содержит объявления нужных нам методов с парой анноташек (реально 0-2 на метод). А дальше всё, только дергаем эти методы. Реализовывать, писать какие-то бины для настройки и творить прочий бойлерплейт не надо. Пагинация, круд и прочее из коробки
Сама генерация реализации происходит одним из трех способов. Или по имени метода (типа findByIdAndNameOrderByName, он сам парсит имя и понимает, что хотим), или по jpql/hql в анноташке Query, или по голому sql в той же самой анноташке
Транзакции делаются одной аннотацией, остальные фичи бд не сильно сложнее. Глубина выборки регулируется EntityGraph и тд. Много всего
Лично я как-то пытался в шарп вкатиться, даже дважды. Как-никак один из мажорных языков, по сути единственный неощупанный у меня. Но каждый раз я натыкался на локальные приколы шарпа (падение перфоманса в 20 раз из-за перестановки 3 множителей в выражении из-за кривого инлайна, любовь разрабов пихать кучу логики в проперти, из-за чего приходится гадать, безопасно ли обращаться в цикле к ним, и тд) и его экосистемы (тот же десктоп - просто мрак и ужас. Куча технологий, и все или заброшены, или в превью, и весь этот монстр Франкенштейна куда-то движется. Winforms, Xamarin, WPF, WinUI, UWP, MAUI... столько всякой хрени, а использовать нечего. Редакторы нормально поддерживают только Winforms и WPF, которые давно заброшены и устарели. WinUI и UWP только появились и сразу сдохли, MAUI вообще до сих пор в превью, но должен заменить в очередной раз все остальное....)
В общем, не сложилось у меня с шарпом и его чехардой)
Для себя выбрал Джаву (на которой и работаю), Котлин (который просто очень вкусный для кроссплатформерной клиентской разработки), Тайпскрипт (веб фронтенд, но в перспективе, когда допилят, мб получится заменить Котлином) и Раст (недавно ознакомился, просто влюбился в язык. Оставил его вместо плюсов для системщины, хочу заодно попробовать сделать бэк на нем, чтобы сравнить в этом с Джавой)
На Скале не писал, ничего сказать не могу.
На Расте у меня это будет первый проект по сути, поэтому тоже все только в будущем. Долго выбирал между Actix и Rocket, остановился на первом в итоге. Не понравилось отношение разработчиков Rocket к проекту и полный провал по перфомансу по сравнению с конкурентом. А у Actix из коробки интеграция с Diesel, вот на него выбор и распространился, т.к. альтернатив, по сути, и нет
Это "мир очень плохих библиотек в джава" по сути еще и лишь по вине автора, который выбрал голый Hibernate и по ходу статьи пытался изобрести кривой аналог Spring Data JPA
Собственно, если посмотреть на Spring Data (которым пользуется большинство в джава-мире), то сразу видно, что там все гораздо стройнее и красивее. И пишется лучше, и самим запросы писать можно, и абстракции на любой вкус, и транзакции декларативные, и генерация запросов по имени метода, и еще куча фич. Вообще красота, буквально 1 строчкой любой запрос делается, 0 бойлерплейта
Лично я все равно предпочитаю Spring Data JDBC или JOOQ (и не люблю ORM в целом), но просто глаза режет от того, что каждый второй пишет про EF, приводя в плюсы то, что есть и в самом используемой библиотеке джавы для бд, просто автор этого, видимо, не знал, или не хотел показывать)
Возможно. У меня другие платформы встречаются только в петах, а там ORM я не использую
Через месяц дойдут руки запилить бэк к пету на Rust, там хочу потыкать хваленую кодогенерацию времени компиляции ORM Diesel, посмотрю на их реализацию
Но в целом, и из хибернейта можно выжать приемлемый SQL, почти всегда. Но зачастую это потребует такой возни с конфигами и жонглирования аннотациями, что десять раз бы уже успел руками написать этот запрос нормально и пойти дальше. И даже в таких случаях результат все равно в 3-5 раз медленнее голого jdbc (у меня получалось в лучшем случае 43с jdbc vs 4,5 минуты hibernate на большом инсерте вложенных объектов в бд)
Плюс, если бы все было так локально, то и поливали грязью бы только хибер, а не все ORM в целом. Я почему-то уверен, что если копнуть поглубже, то и в EF найдутся проблемы
Вот у меня прошлый проект был тем самым кровавым энтерпрайзом. С лютым легаси и тд. И вот там бд была оракл, на 200 000 таблиц и 80 000 хранимых процедур. Запросы писались руками и занимали 5-8 экранов сплошного текста. Я бы скорее сдох от старости, чем заставил бы ORM сгенерировать хоть что-то рабочее на таком объеме данных. И что-то мне подсказывает, что ORM тут могла быть любая, ничего от этого не изменилось бы
Я уже молчу про хинты запросов для планировщика, которые есть в Оракле и, с экстеншеном, в Постгрессе. Что-то я сомневаюсь, что тут тоже можно сгенерировать что-то адекватное по сравнению с тем, что знающий проект человек напишет ручками
Любая известная мне IDE от Jetbrains замечательно с этим справлялась с помощью подсказок. Пишешь имя первого поля, она подсказывает остальные. И дает два варианта - с id и без, для инсерта
Я сейчас работаю на проекте с 2млн строк кода и Hibernate. Насмотрелся на эти гирлянды на всю жизнь. И знаете, когда разница времени выполнения между запросом от хибера и ручным составляет 700 раз, немного задумываешься
Собственно, многие люди и тут, и в крупных компаниях солидарны с моим отношением к ОРМ (достаточно посмотреть на начало этого треда)
Но для фанатиков всегда "не любит мое любимое = ниасилил"
Тогда тем более лучше разделять по бд их. Потому что на таком объеме вы не перегрузите его количеством коннекшенов, но при этом обеспечите 100% изоляцию разных сервисов, просто не давая возможности на уровне бд влезть в соседнюю схему
А давно она проприетарная? Openjdk передает привет. Собственно ей массово и пользуются
А лучше настоящей кроссплатформерностью, гораздо лучшей и стабильной экосистемой и тем, что почему-то именно шарп копирует фичи из джавы, а не наоборот)
Плюс с нее легко уйти в котлин, который подмял под себя весь Андроид и точит зубы на кроссплатформу (десктоп и айос на нем уже достойные)
https://stackoverflow.com/questions/14893964/how-many-schemas-can-be-created-in-postgres
https://postgrespro.ru/list/thread-id/2064050
Был еще один, более актуальный (около 1к схем, а не 10-20к) тред на StackOverflow, но не могу его найти. Там у человека pg_dump вообще крашился
Общая суть в том, что при дампе такой большой бд pg_dump должен развесить кучу локов и все проверить, что очень сильно замедляет процесс (вплоть до невозможности делать это ежедневно) или вообще приводит к его падению
Возможно, в более новых версиях это пофиксили, не проверял (у нас не настолько много сервисов)
Использование отдельных бд требует отдельного коннекшена к каждой, что тоже может стать проблемой. По сути выбор между проблемами с бэкапами или проблемами с коннекшенами
Но в случае отдельных бд мы полностью исключаем использование чужих данных из других схем
Не нужно. Постгря плохо переживает большое количество схем в одной бд. А вот большое количество самих бд - спокойно. Поэтому лучше сразу делать по отдельной бд для каждого сервиса с одной схемой в каждой
Все самое нужное уже в стейбле. Дальше уже QoL фичи идут
Я тут еще об одном нюансе подумал. Веб в котлине превращается в старое-доброе SPA. А веб на флаттере превращается в огромный канвас на всю страницу, на котором уже рисуется все, что надо.
И если SPA тот же гугл уже давно индексирует, то насчет канваса я очень сильно не уверен. Чую огромные, возможно даже нерешаемые проблемы с SEO еще
Я не призываю все бросать и бежать переучиваться. Просто рекомендую ознакомиться людям с альтернативой, которая имхо выглядит вкуснее. Может кому-то понравится больше и он откроет для себя что-то новое и приятное)
Я тут чуть выше оставлял комментарий
Там в конце два проекта на гитхабе с мультиплатформой. Вот в них есть модуль jvm, который билдит приложение с композом в бинарники под любой из 3 десктопов (на самом деле внутри каждого бинаря минимальная жвм, но этого не видно).
А еще есть модуль macos отдельно, где на свифте пишут UI и собирают в фулл натив пол макось, без всяких жвм внутри. Вот никто не мешает повторить это и для других платформ
Если точнее, то не appimage, а exe/dmg/deb/rpm пакет, в котором минимальная жре упакована. Это по дефолту. А ручками фулл натив, да
Так говорите это тому, кто это утверждает ниже. Ну и опять же, с моей колокольни (на флаттере не писал) - если фреймворк зависит от плагинов, то рано или поздно возникнет ситуация, когда нужного плагина нет, и приходится спускаться в натив. Это все уже проходили с Cordova и Ionic. То, что вам пока это не попадалось, не значит, что это не случается. Это архитектурные проблемы таких фреймворков
Он общепринят не по причине легкости. А по причине вендорлока от Эппла. Да, это хреново, но это факт. На свифте огромное количество разработчиков, потому что это единственный фулл натив на IOS, плюс там еще сбоку макось и айпадось стоят
То-то у меня Flutter Gallery - одно из немногих подлагивающих приложений на телефоне (POCO X3 Pro). А "прогрев шейдеров" стал уже притчей во языцех
Свифт привязан к экосистеме эппла. Он хотя бы там нужен много где. А дарт за пределами флаттера - мусор. Тем более после убийства Angular.Dart
Был бы у флаттера любой адекватный язык - я бы и слова не сказал. Но у нас тут очередной $mol, считающий себя настолько крутым, чтобы не сочетаться вообще ни с чем.
И тут сразу же возникают вопросы, ради чего это? Почему люди должны выбрать именно эту поделку и тратить свое время на максимально местячковый язык, а не на альтернативы? И внятного ответа я пока ни разу не получил
Флаттер точно так же требует писать 2+ UI, насколько я помню. Как минимум разные визуальные стили под андроид/айос. Плюс под десктоп совсем другая верстка нужна и под веб
Про платформы - это не только флаттер маскирует. Писать в xcode не требуется, достаточно его иметь. Идея или андроид студия позволяют цеплять его сдк и кодить в нормальных IDE
Было бы еще это правдой) Что про 1 раз, что про 3
Кроме того, я бы предложил все же опустить градус фанбойства и чутка подумать.
Вы серьезно считаете, что кто-то в здравом уме выберет изучение нового языка, нового фреймворка, и переписывание всей кодовой базы, вместо простого размазывания существующей логики на котлине с Андроида на остальные платформы, подключения ее к существующему UI и выбрасыванием аж 3, теперь уже лишних, кодовых баз, и 1 языка?
Он поддерживает, и это таки не только мобильный, это кроссплатформа. А зачем нужен - я уже перечислил кучу плюсов, как для индивидуалов, так и для команд разработки
Попробуйте скомпилить редис в WSL. Или поменять дефолтную версию Джавы в системе. Или поставить Kubernetes для локальной разработки. Или почитайте доку Докера
Везде или через задницу, или вообще невозможно, или "можно, но советуем не трогать винду даже десятиметровой палкой" (краткий пересказ доки Докера)
Не сложнее. Просто половина вещей невозможна, а вторая половина или неудобнее, или лагучее, или нестабильнее)
Может, из-за разницы в железе. Когда у вас в виртуалку прокинуто железо, которым даже не пахнет ни у одного из нативных маков, она, как ни странно, работает быстрее этих самых маков. Вопрос именно в прокидывании этого железа
Ryzen 9 5900X, 32gb DDR4 3200Mhz, SSD 3500MB/s RW, RX 6700 XT
Не самый слабый пк, но и не рабочая станция, и уж тем более не сервер. Ставится в Kubuntu 20.04 спокойно в QEMU, работает тоже спокойно. Ставил себе Big Sur, обновил потом до Monterey
Ноутбуки тут страдают, да. Как и почти во всех остальных аспектах. Однако даже тут есть модели, где люди прокидывали всё
Я же говорю про нормальные пк. Более того, даже там надо заранее учитывать железо, например наличие нормальных настроек IOMMU в чипсете. При этих условиях оно спокойно прокидывается. Да, надо будет заморочиться разок. Зато потом прекрасно работает. Я свое железо подбирал с учетом этих нюансов с самого начала
К слову, любые карты Nvidia, начиная с 10-й серии, не поддерживаются в макоси полностью. Апи Metal просто не работает на них, а визуал макоси на этом построен. Поддерживаются только видюхи самого Эппла, встройки Интела и любые дискретки АМД, включая последние. Собственно в этом может быть ваша проблема, и поэтому ее нет у меня
Если вы не изучили тему, пытались
натянуть сову на глобусзаставить работать изначально несовместимую платформу и закономерно потерпели фиаско, это не значит, что это невозможно в принципеСоветую еще раз перечитать мое сообщение). Предоставляет для всего в стейбле, кроме IOS. Для него вот как раз в анстейбле еще, пока надо свифт использовать
Вы суть потеряли. Во-первых, уже ниже человек писал, что и на флаттере от нативных языков никуда не деться. И, главное, во-вторых, это именно что общепринятые языки нативной разработки, а не конь в своем вакууме, как Дарт.
Давайте посмотрим с точки зрения команды разработчиков. У вас была половина команды на Android с Котлином, половина на IOS со Свифтом, еще отдельная команда для веба на жс/тс и, возможно, десктоп на чем-то.
А теперь мы приходим и предлагаем им сделать мультиплатформу. И даем две опции:
Изучать новый язык, который больше нигде не нужен. Вместе с новым фреймворком. Сохраняя некое дублирование интерфейса, зависимость от плагинов и необходимость иногда спускаться до такого знакомого им натива
Взять уже известные команде, общепринятые языки (Котлин, Свифт, Жс/Тс), но писать теперь на них только UI, и то не везде нужно. А все остальное становится кроссплафтормерным, включая большую часть этого самого UI. И никакой зависимости от плагинов, они могут использовать привычные им библиотеки с натива и тд. При этом по сути и какого-то фреймворка для изучения тоже нет, просто существующую логику с Android растащить на все платформы с минимальными изменениями кода. А отдельный язык для десктопа можно вообще дропнуть, он больше не нужен
Как вы думаете, что они выберут?)
Там как минимум отдельный движок и поток рендера поверх OpenGL/WebGL/Metal. Это уже медленнее, чем фулл натив. Да, скорее всего большинству не критично, но факт
Смотря про какую андроид разработку вы говорите. Android Jetpack в целом и Compose в частности кардинально все упростили там и сделали удобным. И тот же фронт в Композе кардинально от флаттера не отличается. Те же функции, описывающие UI, как и в Реакте
Вы таки не поверите - я знаю, в Котлине это тоже есть)
https://www.jetbrains.com/ru-ru/lp/compose-mpp/
Полностью кроссплафтормерный UI, за бортом только веб и IOS, для которых придется дублировать его (временно, пока решение из анстейбла не выйдет). Точно так же запускается на десктопе, чтобы не мучать тот же AVD
Но от себя добавлю: я врагу не пожелаю разрабатывать под виндой. Линь, только линь. Тем более что там делаются те же самые виртуалки, но с возможностью прокинуть туда железо и обеспечить быстродействие выше, чем у нативных систем. Люди таким образом делают себе макос в виртуалках, который работает быстрее нативного (потому что железо у маков... meh). Ну и виртуалку с виндой для игр, если хочется. Называется VFIO, оно же PCI passthrough
Как вариант. Но по сути уже Compose в стейбле для всего, кроме IOS. А значит можно писать на нем для всего остального и на Swift для IOS, а потом просто избавиться от свифта, когда и туда завезут