в примере как раз приватно все

но да, это было важно, правда щас ругаюсь с override def * = (from, feedback, headers, date_add, ip) <> (Feedback.tupled, Feedback.unapply _) - ну вот не хочет и всё тут. А в примере как раз работает...

Есть подозрение что это из за необходимости использовать import com.github.tototoshi.slick.MySQLJodaSupport.driver.api._, но и его не хочет видеть(

В обещм если кто может сказать почему показывает ошибку type mismatch; found : slick.lifted.MappedProjection[model.Feedback,(Long, String, String, String, org.joda.time.DateTime, String)] required: slick.lifted.ProvenShape[Nothing] - буду очень благодарен, до этого делал - всё работало что не так - не понимаю...

а можешь model.Feedback в gist тоже добавить?

extends Table(tag, "feedback”) -> extends Table[Feedback](tag, "feedback") попробуй

у меня смутное подозрение что дело в этом

а можешь model.Feedback в gist тоже добавить?

model добавил, но там собственно просто case class Feedback(id: Long = 0, from: String, feedback: String, headers: String, date_add: DateTime, ip: String)

а type parameter пробовал добавить к Table уже?

class FeedbackTable(tag: Tag) extends Table[Feedback](tag, "feedback") { так?

да

смотри, ты в IDEA кодишь?

смотри, ты в IDEA кодишь?

угу

идея выводит тип как Nothing, как у тебя в ошибке

override def * : ProvenShape[Feedback] = (id, from, feedback, headers, date_add, ip) <> (Feedback.tupled, Feedback.unapply _)

Вот так в итоге получается олжно быть?

Сделал

Так и выдало, 1 в 1

https://gist.github.com/Visteras/45794cc386ac1f7cc9e8f85cce0722f5

Вот такое в итоге начало выдавать

override def * : ProvenShape[Feedback] = (id, from, feedback, headers, date_add, ip) <> (Feedback.tupled, Feedback.unapply _)

да, по идее так и должно быть

у тебя есть для DateTime мапперы?

Or you use an unsupported type in a Query

У меня есть подозрение что это из-за использования DateTime, с которым по идее я проблему решил

implicit val dateTimeColumnType = MappedColumnType.base[DateTime, Timestamp]( dt => new Timestamp(dt.getMillis), ts => new DateTime(ts.getTime()) )

import com.github.tototoshi.slick.MySQLJodaSupport.driver.api._ вместо import driver.api._

вот насчет импортов на раз сказать не могу

Всё, это я дурак, там было def listAllSortedDateDesc: Future[Seq[Feedback]] = { db.run((for { f <- table.sortBy(_.date_add.desc) } yield f.*).result) }

.* - там такого быть не должно

теперь работает, и это замечательно. Спасибо большое за помощь)

?

это я понимаю приложение play+slick?

прочитал я последние сообщения. эти 40 минут стоили того, чтобы получить отсортированный список объектов? :) </slick-hater>

А если объективно, что сейчас в скале лучшее для работы с БД? quill/squeryll? или лучше вообще просто пользоваться обёртками над jdbc типо scalikejdbc?

я за последнее

но и то я заюзал их query dsl и уже немного жалею в очень сложных запросах

вопрос где много вкусовщины придется перепробовать самому

это теперь не просто месиво из sql, а scala и sql месиво. но там стоит просто на sql написать

вопрос где много вкусовщины придется перепробовать самому

+1

прочитал я последние сообщения. эти 40 минут стоили того, чтобы получить отсортированный список объектов? :) </slick-hater>

Ну это же тролинг)) Так можно сказать про любую новую изучаемую технологию. Всегда тратится время на то что бы въехать как использовать. Сейчас у меня на слике не тратится время на такие вещи. Плюс на нем рефакторить проект одно удовольствие, не надо кучу запросов переписывать каждый раз при изменении сущностей. Плюс это проверяется при компиляции, а не в рантайме, что еще больше времени экономит.

я пробовал слик и мое мнение, что что-то сложнее crud там сложно сделать

после 2 лет использования слика с его багами и очень медленным dsl, doobie это свет в тоннеле, где нет ебли с кривыми запросами и ошибок, когда где-то в дебрях слика происходит None.get

если хочешь сделать сложный запрос, то от тебя уйдет семья и друзья. или ты забьешь

doobie не пробовал, но возможно я теперь предвзят ко всему этому функциональному sql подходу и думаю суть осталась та же

doobie это обертка над jdbc

с фри монадками

а slick?

doobie это scalikejdbc на стероидах

это же все над jdbc, как ни крути

если хочешь сделать сложный запрос, то от тебя уйдет семья и друзья. или ты забьешь

Это просто отличный поинт, чтобы нормально архитектурить приложение. ЧТОб не пришлось потом заниматься извратом)

рекламные лозунги прям ?

а slick это orm, где написать сырой sql запрос с кастомными типами боль и унижение

Это просто отличный поинт, чтобы нормально архитектурить приложение. ЧТОб не пришлось потом заниматься извратом)

ну я например сам отдаю на sql уровне Futute[Result], как я делаю - это неважно, либа мне дает ее или я хоть на голом jdbc делаю запрос, обернутый в фьючу

ну или попробовать добавить туда нативный upsert для pg 9.6

архитектурный вопрос не решается либами

ну или попробовать добавить туда нативный upsert для pg 9.6

в это я и уперся когда-то

после 2 лет использования слика с его багами и очень медленным dsl, doobie это свет в тоннеле, где нет ебли с кривыми запросами и ошибок, когда где-то в дебрях слика происходит None.get

Да собственно никто и не говорит, что слик идеален. Мне от просто непонятно, почему так сильно хейтят его. За год использования ни разу не натыкался на какие-то серьезные баги. Ну и в использовании он простой как палка. Описал поля таблицв и фигаришь 2-3 строки запроса.

там есть pg-extension и это тоже боль

а slick это orm, где написать сырой sql запрос с кастомными типами боль и унижение

Какой ОРМ? Откуда он там?

ну вы меня прямо заинтриговали с doobie

Да собственно никто и не говорит, что слик идеален. Мне от просто непонятно, почему так сильно хейтят его. За год использования ни разу не натыкался на какие-то серьезные баги. Ну и в использовании он простой как палка. Описал поля таблицв и фигаришь 2-3 строки запроса.

а потом тебе нужно добавить пару джойнов, фильтры и твои compiled запросы уже не собираются

Да собственно никто и не говорит, что слик идеален. Мне от просто непонятно, почему так сильно хейтят его. За год использования ни разу не натыкался на какие-то серьезные баги. Ну и в использовании он простой как палка. Описал поля таблицв и фигаришь 2-3 строки запроса.

Есть те кто хейтит, и те кто любит. Слышал и тех и других

ERROR: S client not available

но фри монадки я тоже неочень перевариваю

и запрос в 1-2 мс становится в 80-100 мс только из-за слика

а потом тебе нужно добавить пару джойнов, фильтры и твои compiled запросы уже не собираются

+++ при этом в scalikejdbc это хоть и немного монструозно, но копилируется и работает

и запрос в 1-2 мс становится в 80-100 мс только из-за слика

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

в scalikejdbc ты прям sql конструируешь и не получишь никакого неоптимального sql, если ты не написал его сам

или не построил с помощью dsl соответственно

Плохо, что слик очень медленно развивается. Так то задумка очень удобная, можно ипользовать

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

это не беда, беда когда у тебя в рантайме падает слик из-за ошибок с None.get, как я писал выше и тут начинаются приключения

это не беда, беда когда у тебя в рантайме падает слик из-за ошибок с None.get, как я писал выше и тут начинаются приключения

Ни разу не сталкивался, а из-за чего такое появляется? Может это старая 2.0 версия?

это была версия 3.0 https://github.com/slick/slick/issues/1137

иногда в 3.1 такое бывает, но теперь сложные запросы только через sql"..."

ну серьезные баги везде бывают. в play 2.5.* я не уверен, что до сих пор утечку памяти исправили

это была версия 3.0 https://github.com/slick/slick/issues/1137

Да уж, беда. И кейс-то простой.

и это явно не повод для хейта

я не хейчу слик, но рекомендовать его бы не стал, когда нужно быстро набросать crud

я бы скорее наоборот, когда быстро и crud может и норм, а в долгосрочной перспективе или для чего-то сложного ни за что

я бы скорее наоборот, когда быстро и crud может и норм, а в долгосрочной перспективе или для чего-то сложного ни за что

Так наоборот, в долгосрочной перспективе все поправят. Не? )

А вот если надо чтобы все прямо сейчас, тогда вопрос

мой поинт тут фейл в подходе, а не в библиотеке и ее текущих проблемах

ок, сейчас для меня проблема, что там нет upsert в pg. спустя пару лет они впилят. а за это время еще пара фичей появится, которые фиг заюзаешь опять до обновления

в scalike я это делаю либо просто на sql, либо на query dsl + немного голых sql добавок

и я даже не знаю, как это можно сделать удобнее

ок, сейчас для меня проблема, что там нет upsert в pg. спустя пару лет они впилят. а за это время еще пара фичей появится, которые фиг заюзаешь опять до обновления

самая тема - это aggregate functions, которых в pg оче много, а слик самые базовые

непросто или нельзя в slick совмещать их плюшки и голый sql. тем более компоновать

а в doobie с этим как? если он на scalike, то спуститься на уровень ниже можно всегда?

непросто или нельзя в slick совмещать их плюшки и голый sql. тем более компоновать

в слике же обычный маппинг нельзя переиспользовать для сырого sql, нужно снова повторять имплиситы для SetParamater и GetResult

а в doobie с этим как? если он на scalike, то спуститься на уровень ниже можно всегда?

он не на скалайк, он как функциональная прослойка для jdbc без магии как в slick

если честно, я когда-то этого от slick и ожидал. а там это

если честно, я когда-то этого от slick и ожидал. а там это

+

а да, чем еще бесит слик, так это когда сложный джойн и нужна группировка только по pk одной из таблиц, то слик группирует сразу по всем из таблицы, иначе остальные пойдут как колонки для агрегации. с кастомными типами или колонками типа json в одной из таблиц это настоящая боль. в итоге distinct on и вера в то, что компайлер запросов построит запрос хотя бы в 2 раза хуже ручного (в 3.2 сломали джойны и иногда они становятся селектами без вызова subquery)

что с pg проблемы, что с oracle, что с sqlite. архитектурные решения, рассчитанные на универсальность, не дают его использовать в сколь-нибудь сложных приложениях. если честно, я даже в crud его не беру теперь — простые запросы элементарно делаются на чём угодно