Нет, в exposed есть вполне себе типобезопасная обёртка entity. Так что с полями трудно ошибиться, т.к. они являются полями entity. А api entity максимально приближён к sql запросу. Собственно как и весь dsl exposed. Но есть минусы: нет поддержки хранимых процедур и при большом объёме запросов лучше пользоваться api Table вместо Entity (Всё ещё типобезопасно, но накосячить проще). Из плюсов - инициализация схемы базы данных очень даже минималистичная.
Что же, месье, тогда и я прошу прощения за несколько агрессивную подачу информации. Возможно, я был несколько возмущён ошибками статьи, что мой гнев частично затронул и вас, за что и прошу прощения. А в остальном, спасибо за изложенный вами опыт, серьёзно.
Звучит разумно, но скажите пожалуйста, где я говорил, что нужно ВСЕГДА использовать DAO? Я просто указал на то, что автор статьи его вообще не упомянул. Это раз.
Во-вторых, если уже говорить про сериализацию, то автор использует просто методы расширения. И плевать, что такие методы могут знатно подпортить нервов, когда они вызываются не в том месте, а именно - когда ResultRow не содержит нужных атрибутов.
fun ResultRow.toContact(): Contact = Contact( id = this[ContactEntity.id].value, type = ContactType.valueOf(this[ContactEntity.type]), value = this[ContactEntity.value], userId = this[ContactEntity.userId].value )
Типобезопасно, моё почтение. Скорее "Типо" безопасно.
И, касательно медленности, под капотом там такая же работа с таблицами. Буквально, те же методы. Да и для создания Entity там уж не так много работы лишней не выполняется, только заполнение прототипа данными. Но окей, если доступ к полям объекта таблицы, чтобы этот прототип описать, такая уж тяжёлая задача, то почему месье вообще не пытается использовать корутины, чтобы максимально быстро выполнить запросы? Серьёзно, где они?
П.С. Все операции вставки кэшируются в Exposed, так что один фиг, вставка в таблицу произойдёт только перед считыванием/изменением данных, так что разница в скорости работы обоих методов буквально виртуальная ибо для конечной бд они одинаковы. Но да, документацию читать в наше время - комильфо, коллега.
А месье ловко обошёл стороной встроенный в Exposed механизм DAO, который сильно упрощает работу с сущностями базы данных. На самом деле, используя DAO практически нет необходимости в работе с объектами таблицы напрямую. Использую Exposed более 3х лет, и, как мне кажется, автор ставил целью не рассказать о фреймворке, а рассказать о "ещё одном аналоге, Hibernate".
Нет, в exposed есть вполне себе типобезопасная обёртка entity. Так что с полями трудно ошибиться, т.к. они являются полями entity. А api entity максимально приближён к sql запросу. Собственно как и весь dsl exposed. Но есть минусы: нет поддержки хранимых процедур и при большом объёме запросов лучше пользоваться api Table вместо Entity (Всё ещё типобезопасно, но накосячить проще). Из плюсов - инициализация схемы базы данных очень даже минималистичная.
Что же, месье, тогда и я прошу прощения за несколько агрессивную подачу информации. Возможно, я был несколько возмущён ошибками статьи, что мой гнев частично затронул и вас, за что и прошу прощения. А в остальном, спасибо за изложенный вами опыт, серьёзно.
Звучит разумно, но скажите пожалуйста, где я говорил, что нужно ВСЕГДА использовать DAO? Я просто указал на то, что автор статьи его вообще не упомянул. Это раз.
Во-вторых, если уже говорить про сериализацию, то автор использует просто методы расширения. И плевать, что такие методы могут знатно подпортить нервов, когда они вызываются не в том месте, а именно - когда ResultRow не содержит нужных атрибутов.
fun ResultRow.toContact(): Contact = Contact(id = this[ContactEntity.id].value,
type = ContactType.valueOf(this[ContactEntity.type]),
value = this[ContactEntity.value],
userId = this[ContactEntity.userId].value
)
Типобезопасно, моё почтение. Скорее "Типо" безопасно.
И, касательно медленности, под капотом там такая же работа с таблицами. Буквально, те же методы. Да и для создания Entity там уж не так много работы лишней не выполняется, только заполнение прототипа данными. Но окей, если доступ к полям объекта таблицы, чтобы этот прототип описать, такая уж тяжёлая задача, то почему месье вообще не пытается использовать корутины, чтобы максимально быстро выполнить запросы? Серьёзно, где они?
П.С. Все операции вставки кэшируются в Exposed, так что один фиг, вставка в таблицу произойдёт только перед считыванием/изменением данных, так что разница в скорости работы обоих методов буквально виртуальная ибо для конечной бд они одинаковы. Но да, документацию читать в наше время - комильфо, коллега.
А месье ловко обошёл стороной встроенный в Exposed механизм DAO, который сильно упрощает работу с сущностями базы данных. На самом деле, используя DAO практически нет необходимости в работе с объектами таблицы напрямую. Использую Exposed более 3х лет, и, как мне кажется, автор ставил целью не рассказать о фреймворке, а рассказать о "ещё одном аналоге, Hibernate".