Pierre Andrews

@rafelcustodio, checkout this post about how to deal with options:
http://blog.originate.com/blog/2014/06/15/idiomatic-scala-your-options-do-not-match/

Hey, I used to live in Brazil ;)

you should never call get on an option, this will also throw an exception when it's None, so it would have no benefit over using the int parsing directly. You should use map, foreach and getOrElse depending on what you want to do.

Indeed, it is a tranformer, I didn't go that far as it would have made the post way too complicated. Thanks for pointing it here, I'd already put a link in the last article of the series

Hi @bwbecker, I am glad I could help.

The problem with the DB.withConnection("test") is that the test string is hardcoded somewhere deep in your code (i.e. in your User model), then you have no way of configuring it separately in your test case and in your production app. In addition, it will probably be repeated many times in all the other model objects which access the DB.

The catch is that, you will still have to eventually tell your code what database to use. All the scaffolding presented in this post is to help your configure it as late as possible, so that as little of the code as possible is dependent on a specific implementation and database configuration.

In the final example, I have put MySQLConnection.withUserConnection("default") as an example for a particular action responding to a user request, so this is at the top level of my production code. In the same way, i would have a something like MySQLConnection.withUserConnection("test") somewhere in my test case, or even use another implementation: MockConnection.withUserConnection {...}.

Note also that the string parameter to DB.withConnection in Play is a reference to a key in your application.conf, so you can easily switch SQL database for different production environment by changing this config key.

what do OptionT and run do exactly?