Play Scala and JPA support

[Loic]

Hi,

I was wondering if Play Scala will continue to support JPA models.

The documentation does not reference JPA and "QueryOn" trait anymore.

I find Anorm very elegant but I still like JPA and I would love to be able to use it again.

In some cases, I believe that JPA queries remain simpler than SQL (in yabe sample app, it's very clear).

Maybe it's simpler too to migrate from dev with HSQL to a "real" database in prod with JPA dialects than with plain old SQL.

Loic

[Guillaume Bort]

> I was wondering if Play Scala will continue to support JPA models.

I don't think so. The problem is that JPA and Scala can't work
together properly. There are many problems related to the way of Scala
annotations work, difference in the reflection API, no support for
Scala collection, requirement to use mutable state everything, etc...

> In some cases, I believe that JPA queries remain simpler than SQL (in yabe
> sample app, it's very clear).

Well, not sure. When I rewritten Yabe, I've changed a lot the way the
application access to the database to take part of the power of Anorm.
It can look more complicated but in fact it's just because it mostly
use only one request where hibernate was using several requests to
retrieve the same data set.

Anyway if you prefer something more ORM oriented than Anorm I suggest
you to look at pure Scala alternative like http://scalaquery.org/
instead of Hibernate. It just fits better with Scala.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/ekUzNTl3blZWbXNK.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort, http://guillaume.bort.fr

[Loic]

Ok, so I will carry on with anorm!

By simpler, I mean that JPA queries required less lines of code : on yabe, "findAll" with jpa is replaced by a 4 lines of SQL +  one line of Scala to map this into objects.

But as you said Hibernate makes often more complicated stuff under the hood. 

So I will come back soon on this group to ask you some questions about anorm :)

Thanks,

Loic

[Brian Troutwine]

On Sat, Jun 4, 2011 at 12:34 PM, Guillaume Bort
<guillau...@gmail.com> wrote:
>> I was wondering if Play Scala will continue to support JPA models.
>
> I don't think so. The problem is that JPA and Scala can't work
> together properly. There are many problems related to the way of Scala
> annotations work, difference in the reflection API, no support for
> Scala collection, requirement to use mutable state everything, etc...
>
>> In some cases, I believe that JPA queries remain simpler than SQL (in yabe
>> sample app, it's very clear).
>
> Well, not sure. When I rewritten Yabe, I've changed a lot the way the
> application access to the database to take part of the power of Anorm.
> It can look more complicated but in fact it's just because it mostly
> use only one request where hibernate was using several requests to
> retrieve the same data set.
>
> Anyway if you prefer something more ORM oriented than Anorm I suggest
> you to look at pure Scala alternative like http://scalaquery.org/
> instead of Hibernate. It just fits better with Scala.

This is a bit of a tangent, but I wonder if there is any interest in
decoupling Anorm from Play? It is a very useful and broadly applicable
bit of code. Allowing play-scala to be pulled in as an SBT project
dependency would achieve the same effect with much less work, I
imagine.

I had a stab at performing the decoupling but the validation
annotations require play.data.validation.

--
Brian L. Troutwine

[Ivan Meredith]

+1

2011/6/5 Brian Troutwine <br...@troutwine.us>

[Erwan Loisant]

On Sun, Jun 5, 2011 at 06:13, Brian Troutwine <br...@troutwine.us> wrote:
> This is a bit of a tangent, but I wonder if there is any interest in
> decoupling Anorm from Play? It is a very useful and broadly applicable
> bit of code. Allowing play-scala to be pulled in as an SBT project
> dependency would achieve the same effect with much less work, I
> imagine.

I believe that's Sadek's intention. Actually if you look at Anorm's
code the only dependence on Play code is MayErr, which is a
self-contained 20 lines class.

> I had a stab at performing the decoupling but the validation
> annotations require play.data.validation.

I don't think validation is part of Anorm.

--
Erwan Loisant

[Manuel Bernhardt]

> I don't think so. The problem is that JPA and Scala can't work
> together properly. There are many problems related to the way of Scala
> annotations work, difference in the reflection API, no support for
> Scala collection, requirement to use mutable state everything, etc...

on a related note:

- have you heard of ScalaJPA? I never used it myself, just bumped on
it while reading the scala-announcements list
(https://github.com/dchenbecker/scalajpa)

- what about java JPA Models and scala? (see
http://play.lighthouseapp.com/projects/74274-play-scala/tickets/17).
I'm pretty much interested in that one since I can patch every
upcoming play-scala version myself, but that does not feel very stable
on the long run.

> Well, not sure. When I rewritten Yabe, I've changed a lot the way the
> application access to the database to take part of the power of Anorm.
> It can look more complicated but in fact it's just because it mostly
> use only one request where hibernate was using several requests to
> retrieve the same data set.

I agree, Hibernate can lead to frighteningly bad performance by
churning out 4-5 queries where only one would be enough (and the
performance penalty for each additional query is big). But there are
ways to work around this, e.g. by writing the data fetching in one big
HQL query (instead of navigating the object model). And then the HQL
compiler can become pretty useful I would say.

Yabe is nice and all as a demo app, but for our application we're now
at 47 interconnected tables in the database (not our choice, the
domain model is big and getting bigger as we catch up with
functionality). And I for one do not want to write all the JOINs by
hand in SQL when a compiler can do that work for me.

One idea for the future: what about moving the JPA part of play-scala
into a separate module? That way:
- the interoperability with Java JPA models would be given again (as
long as not used together with the scala-jpa module)
- the interfaces for developing & maintaining another scala-jpa module
for folks that would like to use it anyway would exist.

Thanks,

Manuel

[Sadek Drobi]

Yabe is nice and all as a demo app, but for our application we're now

at 47 interconnected tables in the database (not our choice, the
domain model is big and getting bigger as we catch up with
functionality). And I for one do not want to write all the JOINs by
hand in SQL when a compiler can do that work for me.

The answer is: compiler can't. It is exactly in the context of complex model that frameworks like JPA fail and let you down. And you won't discover it until too late when you start having more than few users. That is our experience and that's the problem Anorm tries to target.

> Well, not sure. When I rewritten Yabe, I've changed a lot the way the
> application access to the database to take part of the power of Anorm.
> It can look more complicated but in fact it's just because it mostly
> use only one request where hibernate was using several requests to
> retrieve the same data set.

I agree, Hibernate can lead to frighteningly bad performance by
churning out 4-5 queries where only one would be enough (and the
performance penalty for each additional query is big). But there are
ways to work around this, e.g. by writing the data fetching in one big
HQL query (instead of navigating the object model). And then the HQL
compiler can become pretty useful I would say.

So this is contradictory. Hibernate will save you writing joins and you'd replace them with HQL fetches? That clearly shows that the model is unintentionally leaky. You define your model upfront not to write queries and then you revert to queries because the model doesn't work!

Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

[Manuel Bernhardt]

Hi!

On Mon, Jun 6, 2011 at 7:40 PM, Sadek Drobi <sadek...@gmail.com> wrote:
>> Yabe is nice and all as a demo app, but for our application we're now
>>
>> at 47 interconnected tables in the database (not our choice, the
>> domain model is big and getting bigger as we catch up with
>> functionality). And I for one do not want to write all the JOINs by
>> hand in SQL when a compiler can do that work for me.
>
> The answer is: compiler can't. It is exactly in the context of complex model
> that frameworks like JPA fail and let you down. And you won't discover it
> until too late when you start having more than few users. That is our
> experience and that's the problem Anorm tries to target.

What I mean with "write JOINs by hand" is not to write the "on" part
or add a where constraint ("... and foo.barId = bar.id") where it is
clear from my relational model where I want to go. I don't expect
Hibernate to generate optimized queries, I just want to write
optimized queries myself in fewer words.

>>
>> > Well, not sure. When I rewritten Yabe, I've changed a lot the way the
>> > application access to the database to take part of the power of Anorm.
>> > It can look more complicated but in fact it's just because it mostly
>> > use only one request where hibernate was using several requests to
>> > retrieve the same data set.
>>
>> I agree, Hibernate can lead to frighteningly bad performance by
>> churning out 4-5 queries where only one would be enough (and the
>> performance penalty for each additional query is big). But there are
>> ways to work around this, e.g. by writing the data fetching in one big
>> HQL query (instead of navigating the object model). And then the HQL
>> compiler can become pretty useful I would say.
>
> So this is contradictory. Hibernate will save you writing joins and you'd
> replace them with HQL fetches? That clearly shows that the model
> is unintentionally leaky. You define your model upfront not to write queries
> and then you revert to queries because the model doesn't work!

I personally didn't revert to queries, I started writing queries right
from the beginning whenever possible because I know too well that
Hibernate won't make nice ones itself. So as said, I don't have many
expectations from HQL - I just expect to write less verbose queries,
that's it.

Just to be clear - I agree with the problem you're trying to solve,
where Hibernate starts working against you instead of for you. All I'm
asking for is to know if there's going to be a place in the future of
play-scala for folks like me who are happy with writing queries by
hand in HQL and/or have an existing Play application written in
play-java and would like to slowly migrate to play-scala.

Manuel

>
> Sadek
> --
> www.sadekdrobi.com
> ʎdoɹʇuǝ

[Crusoe]

Having developed in a jdbc style framework, its verbose, ugly, and
error prone. The combinators are cute, but the proof is in the
pudding.

Also, persistence libs have about a decade of work behind them,
whereas Anorm has only been around for a little while.

The existing JPA play infrastructure also allows the use of multiple
different database backends, and can even be adapted to other stores,
as is seen with the Morphia plugin.

Anorm forces you to use a RDBMS currently.

Anorm is immature and too feature incomplete currently to even hope to
displace the JPA support in Play-Scala.



On Jun 6, 11:48 am, Manuel Bernhardt <bernhardt.man...@gmail.com>
wrote:
> Hi!

>
> On Mon, Jun 6, 2011 at 7:40 PM, Sadek Drobi <sadek.dr...@gmail.com> wrote:
> >> Yabe is nice and all as a demo app, but for our application we're now
>
> >> at 47 interconnected tables in the database (not our choice, the
> >> domain model is big and getting bigger as we catch up with
> >> functionality). And I for one do not want to write all the JOINs by
> >> hand in SQL when a compiler can do that work for me.
>
> > The answer is: compiler can't. It is exactly in the context of complex model

> > that frameworks likeJPAfail and let you down. And you won't discover it

> play-scalafor folks like me who are happy with writing queries by

[Erwan Loisant]

On Wed, Jun 8, 2011 at 20:21, Crusoe <daniel....@gmail.com> wrote:
> Having developed in a jdbc style framework, its verbose, ugly, and
> error prone. The combinators are cute, but the proof is in the
> pudding.
>
> Also, persistence libs have about a decade of work behind them,
> whereas Anorm has only been around for a little while.

With this kind of reasoning we'll be all using cobol today.

> The existing JPA play infrastructure also allows the use of multiple
> different database backends, and can even be adapted to other stores,
> as is seen with the Morphia plugin.
>
> Anorm forces you to use a RDBMS currently.

Obviously, if you don't want to use a relational database you don't
want to use Anorm. This is actually not going to change: Anorm will
never get a MongoDB backend. This doesn't mean you must use Anorm in
your play scala projects.

I don't think having a common abstraction layer on the top of
relational databases and json databases like MongoDB. They have a very
different approach, so the you should think carefully when you decide
which one you use at the beginning of your project. It doesn't make
much sense to switch from one to the other without a major rewrite of
your models.

> Anorm is immature and too feature incomplete currently to even hope to
> displace the JPA support in Play-Scala.

No matter how you like JPA, it doesn't work correctly with Scala. Even
if you don't like Anorm you should still use a non-JPA Scala ORM, like
Circumflex ORM for example.

--
Erwan Loisant

[Ivan Meredith]

Play is immature, jee has been around for ages, why not use that?. Well I tried, honestly I really did, but jee just makes me depressed, as does JPA (and most other jee technologies)

play-scala + anorm makes me smile. I can work around the immaturity it has at the moment.

You should be looking at what the right tools are for every project you do. For me, play-scala + anorm is right. For you, maybe not, but that doesn't make it bad or wrong.

[Ivan Meredith]

Yeah with abstractions you limit the use of any given service that is abstracted, unless they all have the same feature sets. I don't see the point to have sql and nosql abstracted into one api, I doubt you would benefit from using nosql if you did that (or if it was targeted at nosql, sql would suck)

[Adam Jorgensen]

There are pros and cons to both JPA and Anorm as I see.

They both have their strengths and weaknesses.

Still, as others have said, Anorm + ScalaQuery are better bet than JPA
+ Scala

[Xuefeng Wu]

ScalaQuery and Anorm could work together, Is there any example?

[Adam Jorgensen]

Well, you could probably use them in parallel. 

I don't think you could, for example, use Anorm to retrieve a bunch of ScalaQuery objects.

Which is probably not the best thing to do in life, but hey there you go :-)

On 18 June 2011 04:36, Xuefeng Wu <ben...@gmail.com> wrote:

ScalaQuery and Anorm could work together, Is there any example?

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/Lw5YOPooH88J.

[Pascal Voitot Dev]

I begin to think of implementing Siena for Scala because I begin to get interested a lot in Scala and because I think it could be fun to have Siena model translated to Scala.
Anorm is an interesting api that could be used in parallel of something like Siena (in SQL for the time being) but I wonder whether inter-connecting both in some way could be possible and interesting...

regards
Pascal