scala, play & MySQL

132 views
Skip to first unread message

David Pichsenmeister

unread,
Apr 7, 2014, 11:40:53 AM4/7/14
to scala-...@googlegroups.com
hey guys!

i'm starting to use scala & play in a project. i already have a mysql db schema.
what would you recommend to use? any orm which fits good into scala/play or any experience (bad or good ones)?

thanks!

cheers,
david

Christian Papauschek

unread,
Apr 8, 2014, 5:22:27 AM4/8/14
to scala-...@googlegroups.com
David, in case you’re considering to pick Slick, I would be willing to help with any questions you may have ;-)

We’re using Slick with MySQL here at miavia for more than one year now, and pretty happy with it. If you feel comfortable using for comprehensions and other constructs for handling lists in Scala, I’d say go for it.

If you would feel more comfortable writing SQL than using a scala collections-like api, I’d say look for something else.

Hope that helps,
greetings to Berlin :-)
Chris


Sebastian Nozzi

unread,
Apr 8, 2014, 9:41:45 AM4/8/14
to scala-...@googlegroups.com
Hi David,

as Christian mentioned there is Slick, which is the way to go if you want a Scala-idiomatic, functional framework backed up by Typesafe.

I, personally, didn't like the verbose "repeat yourself" that you are forced to when defining your "schema". That's why I looked for alternatives and ended up using Squeryl and even ActiveRecord (which builds on top of it).

There is also the activate-framework which, although interesting, I have not yet used. Also worth checking are "sorm" and "circumflex orm".

Finally, yesterday we learnt about jOOQ, which has decent Scala support. Also check scalikejdbc.

Hope this helps.
Cheers,

Sebastian




--
You received this message because you are subscribed to the Google Groups "Vienna Scala Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-vienna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Pichsenmeister

unread,
Apr 8, 2014, 1:23:04 PM4/8/14
to scala-...@googlegroups.com, sebn...@googlemail.com
thanks chris & sebastian for your answers and also for offering your help :)

after reading the docs, i think Slick oder ActiveRecord would fit best in my project, but it's definitely going to be a hard decision ;)

i'll let you know, which it will be ;)

cheers,
david

Sebastian Nozzi

unread,
Apr 8, 2014, 1:40:49 PM4/8/14
to David Pichsenmeister, scala-...@googlegroups.com
Slick or ActiveRecord? But they are like... very different, aren't they?

Some questions to help you decide:
  • Is your project long term or short term?
  • Is it a one-man project or will it involve more people?
  • Is it serious (involves real users / customers) or a hobby project?
  • Do you want ORM or can you live without it?
  • Do you want a strict separation between DAO layer and your model classes, or are you ready to sacrifice "cleanliness" for pragmatism?
  • Do you need to understand the framework under the hood?
  • Would you mind if you had to implement a feature in the framework yourself? 

Sebastian Nozzi

unread,
Apr 8, 2014, 2:00:58 PM4/8/14
to David Pichsenmeister, scala-...@googlegroups.com
Hey... you can also combine both. Not that I recommend it, but I have done it (was transitioning out of slick but abandoned the process. So I have some DAO classes that use Slick and others use ActiveRecord).

David Pichsenmeister

unread,
Apr 8, 2014, 2:35:08 PM4/8/14
to scala-...@googlegroups.com, David Pichsenmeister, sebn...@googlemail.com
yes, they are.

ActiveRecord seems to be quite lean (and i like that).
but since i already have a mysql schema defined by another orm (from php. yeah, i know. php... :/ ), i don't know if everything is working out with ActiveRecord.
So, Slick seems also like a good choice, since you define your classes in a very straight forward mysql way.

to the questions:
  • long term
  • atm we are 2 people, but likely more soon
  • serious project
  • i would prefer an orm, but the defined schema is more important (or: the php orm is the main orm)
  • i'm ready to sacrifice ;)
  • no
  • i would prefer to use it as it is.  
and i would prefer not to combine them.

Christian Papauschek

unread,
Apr 9, 2014, 8:02:48 AM4/9/14
to scala-...@googlegroups.com, David Pichsenmeister, Sebastian Nozzi
since you already have a schema, you could use slicks code generator to generate the scala table definitions for you:

(also talks about database migrations)

Cheers,



--
You received this message because you are subscribed to a topic in the Google Groups "Vienna Scala Users' Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-vienna/boHktdYWFs8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-vienna...@googlegroups.com.

David Pichsenmeister

unread,
Apr 9, 2014, 12:01:58 PM4/9/14
to scala-...@googlegroups.com, David Pichsenmeister, Sebastian Nozzi
wow. that sounds great. i'll give it a try.

thanks!

David Pichsenmeister

unread,
Apr 10, 2014, 2:14:03 PM4/10/14
to scala-...@googlegroups.com
hey chris!

i checked out your code generator and it works fine. 
but, i still have some problems: i generated the classes from the generator and got two classes for each entity: Entity and EntityRow.

what's your best practice to deal with the entities and doing CRUD operations?
working with the EntityRow and defining CRUD operations in a DAO?

and at least: i have a boolean field, which is converted to tinyint(1) in mysql. when generating the classes from my schema, the field is treatened as Byte in Scala. Any Ideas how to handle that?

slicks seems to be far away from easy to learn or easy to understand :/
anyway, i think i have to handle it ;)

thanks & cheers from berlin ;)
david

Christian Papauschek

unread,
Apr 10, 2014, 3:12:27 PM4/10/14
to scala-...@googlegroups.com
hi David,

yeah, the documentation of Slick is still lacking, the most important concept to grasp is that you actually have to forget SQL, and think "scala collections". then you can more easily build complex queries in slick.

personally, in my projects I use the "EntityRows" all over the place. since they are just case classes. they dont have any DB-specific stuff attached. I also serialize them to JSON sometimes and use them in the frontend.

depending on the number of transformations involved between database tables and final display-data of the web application, you might want to introduce another level of intermediary objects in order to keep database stuff from application logic more separate. It really depends on the project.

regarting Boolean vs. tinyint mapping: I suggest you adapt the slick code generator to your needs. see this documentation here:

slick maps tinyint to boolean just fine, but you have to tell your codegenerator to generate Booleans instead of Bytes.

if you find yourself changing a LOT of the things in the generated code, why not drop the generator altogether and include the generated code in your project so you can change it directly?

Cheers,
Chris

David Pichsenmeister

unread,
Apr 10, 2014, 4:25:31 PM4/10/14
to scala-...@googlegroups.com
thanks chris,

that helped my a lot. my application is just a REST backend which deals with some json data, so no need to introduce a layer in between. i'll just use "EntityRows" as they are.
Reply all
Reply to author
Forward
0 new messages