Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lift and database access?

 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the things I really like about Play!, and the reason used I used it for a handful of projects despite the many things that I don't like about Play!, is its fairly seamless integration with Hibernate/JPA that factors away most of the pain of dealing with databases.

How does Lift fare in this space?

Nothing drives me crazier than having to deal with JPA and Hibernate nonsense.
 
Timothy Perrett
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:One of the things I really like about Play!, and the reason used I used it for a handful of projects despite the many things that I don't like about Play!, is its fairly seamless integration with Hibernate/JPA that factors away most of the pain of dealing with databases.

How does Lift fare in this space?

Nothing drives me crazier than having to deal with JPA and Hibernate nonsense.


Personally I avoid JPA like the plague. There is support for a more reasonable abstraction of working with JPA (chapter 13 in LIA), but you very much still know you're working with JPA. It's essentially a wrapper on JPA to give the API more of a Scala feel. Depending on how much JPA you need to use, this may or may not eliminate some of the pain.

Lift does ship with its own database layers, but you are in no way bound to use them. I typically don't use Mapper (lifts ORM) at all, rather, I use ScalaQuery when I need to interact with RDBMS. There are several very excellent database abstractions in the Scala eco-system, so it doesn't pay to be tied by the one that a particular framework brings to the table (that goes for both Lift and Play!)

Cheers, Tim
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Timothy Perrett wrote:Personally I avoid JPA like the plague.


I hear you!

Again, that's one of the things I like about Play!, except for annotating the models, you hardly know that JPA is in use.

So you are saying that the Lift/Scala ecosystem has numerous DB access choices and that you can pick the one that best suits your project or programming style?

Is there one that's similar to Play's ORM approach? Is there an even simpler (as in straight-forward) choice? Which would you use for a RESTful web service that's mostly a glorified CRUD layer?

 
Timothy Perrett
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
Timothy Perrett wrote:Personally I avoid JPA like the plague.

So you are saying that the Lift/Scala ecosystem has numerous DB access choices and that you can pick the one that best suits your project or programming style?


Yup this is exactly what I'm saying.

Bear Bibeault wrote:
Timothy Perrett wrote:Personally I avoid JPA like the plague.

Is there one that's similar to Play's ORM approach? Is there an even simpler (as in straight-forward) choice? Which would you use for a RESTful web service that's mostly a glorified CRUD layer?


Similar to AnORM? I don't think so. Personally I don't like that kind of approach as I prefer something typesafe like ScalaQuery which is the absolute awesome :-)

Cheers, Tim

 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm all ears -- can you give a capsule summary of the ScalaQuery approach and what makes ScalaQuery so awesome?

(DB access has always been a thorn in my side, so I'm always looking for better ways.)

 
Timothy Perrett
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:I'm all ears -- can you give a capsule summary of the ScalaQuery approach and what makes ScalaQuery so awesome?

(DB access has always been a thorn in my side, so I'm always looking for better ways.)



Database queries using monad comprehensions... what's not to like :-D Here's an example:

for {
c <- Coffees
s <- c.supplier
_ <- Query groupBy s.id
} yield s.name.min.get ~ c.name.count

Super, super nice as its all typesafe, and if it doesn't compile, the query wouldn't run. Essentially anything that compiles is a valid query.

 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65115
89
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know enough Scala (as in none) to grok what all that means, but I like "typesafe".
 
Hussein Baghdadi
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is ScalaQuery the equivalent to .NET LINQ?
 
Timothy Perrett
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hussein Baghdadi wrote:Is ScalaQuery the equivalent to .NET LINQ?


I'm not hugely familiar with link, but scalaquery only works with RDBMS, not say, XML files or whatever which I think LINQ does?
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Knowing nothing about ScalaQuery other than what's written above, it looks to me that you could possibly consider it equivalent to the LINQ to SQL (or LINQ to Entities) part of .NET. LINQ allows you to use a similar programming style against anything that has a LINQ provider - which includes XML files and the collections framework as well as databases. From the above ScalaQuery seems to allow you to use databases in a similar way to how you'd traverse and transform collections in Scala. So both technologies are letting you have common language idioms for disparate sources of data.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic