Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factor out ebean from Play Java, factor out anorm and use JPA and Slick #1518

Closed
huntc opened this issue Aug 23, 2013 · 45 comments

Comments

Projects
None yet
@huntc
Copy link
Contributor

commented Aug 23, 2013

The Ebean project looks to be inactive. We should be using JPA where Slick isn't being recommended i.e. drop anorm also and boil our built in db support to JDBC, JPA and Slick.

@mandubian

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2013

+1
Is slick support prod-ready for play2?
Le 23 août 2013 09:58, "Christopher Hunt" notifications@github.com a
écrit :

The Ebean project looks to be inactive. We should be using JPA where Slick
isn't being recommended i.e. drop anorm also and boil our built in db
support to JDBC, JPA and Slick.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1518
.

@seantbrady

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2013

I'm in favor of Play moving from Ebean to JPA as the preferred DB tool if Ebean's development is stalled. However, subscribers like me who have apps with hundreds of Ebean models will need the Ebean play module maintained for some extended period of time.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Aug 23, 2013

Hi @seantbrady. Please be assured that we would deprecate the support over a sufficient amount of time in order to facilitate customer migration. Please also note that a decision has not been made and your input is important to us.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Aug 23, 2013

Hi @mandubian re slick, just looking forward in time, possibly end of year. :-)

@liutaon

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2013

Hi, @huntc , How about play-slick? I am going to use it with play 2.2.

@diwa-zz

This comment has been minimized.

Copy link

commented Aug 24, 2013

I have also recently adopted play-slick on a new project with play 2.2.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Aug 24, 2013

Yes, I think play-slick makes sense. Need to evaluate further of course.

@bigjason

This comment has been minimized.

Copy link

commented Aug 28, 2013

Any hope of extracting anorm to its own project? Be very helpful to those of us committed to it.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Aug 28, 2013

That's a good suggestion @bigjason - thanks

@jroper

This comment has been minimized.

Copy link
Member

commented Oct 16, 2013

We should rescope this to just ebean. While moving anorm into a separate project is something we should eventually do, I think we should keep it around for longer than ebean, it's not causing anyone any troubles like ebean is, it's a very low maintenance cost for us, and many people love it and find it very useful. Ebean on the other hand is high maintenance, people are complaining about it, and it's causing lot's of troubles. So I think we should have slick and anorm coexisting for a time first.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Oct 16, 2013

I was thinking that anorm would become its own project/repo though - this would facilitate a separate lifecycle and potentially help grow a community around it. Once we integrate play-slick then I don't really see why anorm should be part of its core. Further thoughts?

@jroper

This comment has been minimized.

Copy link
Member

commented Oct 17, 2013

I don't think there is a community ready to accept maintenance of it though. So, at least initially, it will be us that has to maintain it. It's easier to maintain if it's part of play core.

@diwa-zz

This comment has been minimized.

Copy link

commented Oct 17, 2013

I am not sure if anorm has a life or future of its own.
Would it be possible to offer a transition path/facade to the sql embedding of Slick

@bthule

This comment has been minimized.

Copy link

commented Oct 23, 2013

Will the Play1.1 play.db.jpa.Model come back in Play 2.3?

(It's sad to see ebean fall apart. I much preferred it over JPA and Hibernate)

@srnm

This comment has been minimized.

Copy link

commented Oct 23, 2013

"We should be using JPA where Slick isn't being recommended" ?

Can someone elaborate on the use cases where Slick/play-slick isn't a good fit?

thanks

@bthule

This comment has been minimized.

Copy link

commented Oct 23, 2013

Slick is only available when using Scala. JPA is a much better fit than Slick when using Java. I am not sure if anyone would recommend JPA over Slick when using Scala, but if JPA was a better choice for your scenario, you'd probably know it-- possibly because you were already using JPA on other projects.

@tavlima

This comment has been minimized.

Copy link

commented Nov 14, 2013

Just for you guys to know, Ebean's development is not stalled at all, as you can see from their github repo.

https://github.com/ebean-orm/avaje-ebeanorm

I, personally, think Ebean suits Play very well, being that simple and reducing the overheads of other JPA implementations. I'd really ask you NOT to remove it, if possible. Try to move it to a plugin or something, but keep it as easy to use as it is, now. Pure JPA implementations and replacements should be, of course, an alternative for those seeking it's features.

@bachi76

This comment has been minimized.

Copy link

commented Nov 14, 2013

Just to add one more voice. We've started a large project here with Play a while ago. While working with Play is great, Ebean soon became the one major pain point: Expected things did not work, many errors (confirmed as such in the web), no JPA2 features, lack of proper documentation etc. All in all, it consumed much more time than we expected as soon as the model got a bit more complex. We've now migrated to JPA, this took a while, but it was totally worth it: Now we have a solid, very well documented foundation we can rely upon. This makes a huge difference in motivation and productivity in our team. We only hope that JPA will become the supported standard soon.

@dominicwilliams

This comment has been minimized.

Copy link

commented Nov 14, 2013

The death of Ebean has been greatly exaggerated. Largely this is down to a comms failure, which is about to be rectified. Here is an update.

** Ebean website **

  • See http://dominicwilliams.github.io/ebean-website/ (under development website)
  • This will shortly reside at http://ebean-orm.github.io once Rob Bygrave has added some stuff
  • The new website will transform the Ebean experience for existing users and new users alike. Until only yesterday avaje.org homepage linked to version 2.7.0 Source Forge while latest 3.2.4 version is on GitHub
  • New documentation will cover all areas of usage in structured way, with examples, Quick Start guide etc
  • Key limitations will be shared e.g. Ebean uses JPA 1.0 annotations only, and many users get stuck trying to make JPA 2.0 annotations work
  • Etc

** Ebean development **

  • While it is true Ebean development hasn't been rocketing forwards, it is not dead either. Actually the 3.2.4 release was made 11th September 2013 (part of problem is that only completed work is checked in to GitHub giving impression of no coding activity, which will change)
  • Currently there is a version 4.0.0 under development by Rob Bygrave right now. The objective is to simplify Ebean's internals further and remove extraneous features. This will make 4.0.0 leaner and meaner & importantly also provide a good entry point for new developers who want to get involved

** Ebean advantages **

  • I liked the Ebean approach but spent some weeks sanity testing alternatives for a new project including EclipseLink (JPA 2.1), QueryDSL and JOOQ. The advantages of the Ebean architecture stand.
  • For example, take the Ebean lazy loading/partial object model
    • Why load more fields than you need for a particular operation?
    • What if you only need fields that are in the index... loading all fields kills performance
    • And... this works great with modern Web development approaches like angular.js.... now you just load the parts of the object you want for your angular model and use JSON functionality to serve just the required view over REST
  • I like the way that Ebean shows you the SQL generated at even the lowest logging level. The objective is not to be some monstrous layer you will be lost in when it goes wrong
  • Some features like auto-fetch tuning have enormous potential within high performance applications
  • Simple code, easy to understand, great for agile.
  • And there's tons of other goodness too

And please remember that the other ORM solutions can be also be frustrating. For example, playing with EclipseLink 2.5 I was confounded by its tendency to uppercase table names in certain queries causing my MariaDB database, which is case sensitive, to throw. The way around this was specifying the table name in the EclipseLink-specific orm.xml file (yup, the reference implementation for JPA 2.0 was ignoring the case of the table name in the @table annotation even when quotes are used forcing me to violate DRY by putting it in orm.xml too. Hmmm...).

** Play issues **

Hopefully the new website will greatly improve the situation for Play Ebean users, but some kind of dialog would be useful between Ebean and Play. For example, Play's "custom" approach of asking people to derive from the Model class is problematic.

  • When they hit problems, they can't be reproduced outside of the Play framework, making it harder to support them
  • Anyway usually you want to stuff your model into a separate jar that can be re-used between different projects. For example I keep my model in a special jar where it is accessible to scripts. But since I don't derive from Model (I think this is the reason) Play doesn't do dynamic enhancement and I am forced to use static enhancement via the Ebean Maven plugin, which luckily works fine.

So anyway, my personal view is that it would be better for Play to stick with Ebean for now, because it could potentially add a lot of value to the system, and for there to be some dialog in relation to optimizing how the two can work together. Play might also like to encourage contributions come version 4.0.0.

Let me know what you think

@seantbrady

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2013

@dominicwilliams This is great news and a great write-up. We've been using Ebean since Play 2 was released and with hundreds of models, we won't be changing any time soon. Communication and documentation have definitely been sticking points, so I'm glad to hear about these improvements.

@dominicwilliams

This comment has been minimized.

Copy link

commented Nov 15, 2013

@seantbrady thanks if you have any particular views on information or
examples that really needs to be in the docs, please forward them.

On Thu, Nov 14, 2013 at 1:12 PM, seantbrady notifications@github.comwrote:

@dominicwilliams https://github.com/dominicwilliams This is great news
and a great write-up. We've been using Ebean since Play 2 was released and
with hundreds of models, we won't be changing any time soon. Communication
and documentation have definitely been sticking points, so I'm glad to hear
about these improvements.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1518#issuecomment-28523214
.

@jroper

This comment has been minimized.

Copy link
Member

commented Nov 15, 2013

At the end of the day, there are two tasks involved in this issue:

  • Making JPA the default option instead of ebean.
  • Pulling ebean out of the core Play codebase (it's already an optional plugin) into its own GitHub repo, which at least initially, would still be maintained by the Play core team, but may eventually be taken over by the community.

The first becomes less relevant every day, we are moving away from the "traditional" play distribution and instead moving to Typesafe Activator as the preferred way to get started with Play. Typesafe Activator comes with a rich variety of templates to start from, so there is no longer one default template. In addition, we are working towards making it easier to use Play without any distro at all, just vanilla SBT, in which case, there is no template at all.

The second we are not set in stone on - if someone can make a good enough argument for keeping it in Play core, then we'll keep it.

I agree that more communication between Play and ebean would be good. In particular, if @dominicwilliams or @rbygrave want to make suggestions regarding extending the Play Model class (should we deprecate it?), we'd be most open to hearing them.

The big thing that I'd like to see from ebean is the reference guide available as a set of HTML pages. The inability to link to it, either from our docs, or from our mailing list when helping people, the inability for google to return results from it (maybe it can, but it never does), and general unfriendliness of PDF readers compared to accessing things from the web majorly inhibits Play's ability to provide a great experience with ebean.

@bthule

This comment has been minimized.

Copy link

commented Nov 15, 2013

Since Ebean is not inactive, can it please be kept as the default option instead of JPA? Ebean is a much better fit for Play than JPA. I personally can't stand JPA because of how difficult it is to configure to get optimal queries. I still think it makes sense over JDBC, but sometimes I wonder. Anyway, Ebean removes all the pain JPA inflicts, and I would rather see new developers learning on Play not think JPA is good because Play gives it preference over Ebean.

@dominicwilliams It's awesome news to hear Ebean is not dead. I think the reason people think its dead was because the website and docs were unavailable for months, and then right after that i think @rbygrave said he wasn't going to work on it much anymore, but he would do one last sprint to remove out hard to maintain functionality-- and then after that, he would only do light maintenance in his non-existent spare time. That's what I remember, but maybe I am mistaken? I really like the new website. Maybe use the new websites's front page as it sits now and then link to the old site underneath. I'd like to see a roadmap to show where it's heading.

@jroper you should take a look at the new website @dominicwilliams posted -- it already has an outline for the documentation to be in HTML.

@diwa-zz

This comment has been minimized.

Copy link

commented Nov 15, 2013

EBean's stateless approach is the right fit for the reactive play. It will be great if there is a some joint effort in optimizing this story.

I initially tried hard to use EBean but turned away for two reasons

  • Really unclear about what works and what doesn't work
  • Sporadic activity, long-standing bugs, non-availability of maintainers, opacity of codebase

However, the story had a happy ending as i discovered scala and slick !!

@hepin1989

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2013

seems like ebean is not dead
Release News

11 Sep 2013 - Release 3.2.4: Bug fixes
02 Aug 2013 - Release 3.2.3: Bug fixes
12 Jul 2013 - Release 3.2.2: Bug fixes
26 Apr 2013 - Release 3.2.1: Restructor of project, Feature removal, Bug fixes

@nonameplum

This comment has been minimized.

Copy link

commented Nov 28, 2013

I'm also voting to not replace Ebean - most important stateless.

More important should be make Play core independent to database access framework.

So Ebean should be plugin for Play framework.
Then programmer can pick the right choice for him for database access.

@jroper

This comment has been minimized.

Copy link
Member

commented Nov 29, 2013

ebean is a plugin, and Play is independent from the database framework.

@jensjaeger

This comment has been minimized.

Copy link

commented Jan 16, 2014

When JPA gets the default. It would be great to have some more JPA features. A ebean like finder would be great. I published my solution for a JPA finder with hibernate and other JPA related stuff to https://github.com/jensjaeger/play4jpa. It's still work in progress. I hopefully have time soon to improve it.

@jtammen

This comment has been minimized.

Copy link

commented Jan 16, 2014

@jensjaeger +1, that would be great, indeed!

@poornerd

This comment has been minimized.

Copy link

commented Feb 14, 2014

uh @jensjaeger +1

@loicdescotte

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2014

Indeed it would be great to have a Model helper
Play 1.x JPA support was very nice, I think @jensjaeger 's module is very good too, it would worth to be part of Play's JPA support

@adis-me

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2014

I am totally against Play's attitude towards removing Ebean. It just feels like no support will be available for Ebean in the future especially when we know, at this point that Ebean is not dead. Play 1 and Play 2 is written by and for WEB developers (mentioned in the first paragraph of the Play for Java book) and not J2EE developers. I like this thought. So assuming every java web developer know Hibernate is a wrong assumption, in my view.. I have never worked with hibernate or jpa and this was Play's selling point for me. Play with Ebean was my combination for being a productive WEB developer but at this point i am afraid to start any new project with Ebean... Without Ebean my feeling is that Play is less a WEB framework compared to Django or Ruby where Play was getting their inspirations from...

@bachi76

This comment has been minimized.

Copy link

commented Feb 26, 2014

Are you aware that Ebean and JPA are actually pretty close? And that JPA2 just adds a bunch of more powerful features? There's really no need to worry about JPA (just Play's JPA integration should get some small optimisations).

----- Ursprüngliche Mail -----

I am totally against Play's attitude towards removing Ebean. It just feels
like no support will be available for Ebean in the future especially when we
know, at this point that Ebean is not dead. Play 1 and Play 2 is written by
and for WEB developers (mentioned in the first paragraph of the Play for
Java book) and not J2EE developers. I like this thought. So assuming every
java web developer know Hibernate is a wrong assumption, in my view.. I have
never worked with hibernate or jpa and this was Play's selling point for me.
Play with Ebean was my combination for being a productive WEB developer but
at this point i am afraid to start any new project with Ebean... Without
Ebean my feeling is that Play is less a WEB framework compared to Django or
Ruby where Play was getting their inspirations from...


Reply to this email directly or view it on GitHub .

@adis-me

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2014

I know they are both based on the javax specification (annotations on the model), this is what you mean right?. But JPA has no Finder method, just to give an example. I know James Ward made a sample Jpa project but it just does not feel correct. Also when trying to read docs about Jpa i get hibernate documentation and that scares me 👎

@jroper

This comment has been minimized.

Copy link
Member

commented Feb 26, 2014

It sounds to me like a lot of people are quite passionate about ebean. If we pull the support out of Play, it will allow the following:

  • Play's ebean support will be able to move independently of Play's releases. Bugs can be fixed and released the next day.
  • We can easily bring on community committers, who can be more active in maintaining it.
  • More radical changes can be made to ebean support for the better, since it won't be constrained by Typesafe's binary compatibility policies.

ebean support is not high in the priorities of the core Play team. Keeping it in Play framework therefore only restricts it, pulling it out will probably really help it.

@bachi76

This comment has been minimized.

Copy link

commented Feb 28, 2014

Yes, Ebean claims also to borrow from the JPA specification "to some extent" (which in our experience made it sometimes hard to find the proper documentation for Ebean).

@play Devs: We had one major issue with Play's JPA integration: There seems no way to merge data from a Play form to an existing JPA entity: Play uses JPA's merge(), which however doesn't really merge but copy - it seems not possible to merge data from a play form with its stored entity if the form does not contain all attributes. The JPA example does omit that by having all entity attributes in the form, which however isn't often the case in real-world situations. Hope this can be solved soon (we've created a solution but it would be great if it could be properly solved in the framework).

----- Ursprüngliche Mail -----

I know they are both based on the javax specification (annotations on the
model), this is what you mean right?. But JPA has no Finder method, just to
give an example. I know James Ward made a sample Jpa project but it just
does not feel correct. Also when trying to read docs about Jpa i get
hibernate documentation and that scares me


Reply to this email directly or view it on GitHub .

@Ronnie76er

This comment has been minimized.

Copy link

commented Feb 28, 2014

I agree with @jroper. We encountered a bug in ebean that @rbygrave was quick to fix. To get the fix, we're including a dependency on ebean 3.2.5. This is sitting next to the 3.2.1 jar in our distribution, which doesn't make me feel great.

@bthule

This comment has been minimized.

Copy link

commented Feb 28, 2014

Yeah, what @jroper says makes sense. But just so long as JPA doesn't get higher preferential treatment. I still think when someone gets a "starter kit" for Play, that ebean is a better fit for inclusion.

@bachi76 It is debatable that JPA is more "powerful" than Ebean. JPA's "declarative" approach to querying requires complex declarative annotations and entity graphs. This is time consuming to develop, and it isn't intuitive to code. Ebean's "programmatic" approach to querying is simple. It relies on the programmer to know what data the code will need later, and then you write the query code that way-- with a clean simple API. I have a lot of experience with JPA-- and only a small project with Ebean-- so maybe I just haven't worked with Ebean enough to know more of its pitfalls, but for the things that JPA caused me the most pain with-- and caused me weeks and months of "optimization" pain-- Ebean solved them with its simple query API. So from that perspective, I would say Ebean was more powerful. And in the interest of making new Play developers happier, I do think Play should gently lead people to making a choice for Ebean.

@adis-me

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2014

I agree with @bthule. If we want to make Play more attractive to the (new age) (Java) web developers we should still promote Ebean as first choice to work with. Do not get me wrong, making it a plugin is not a bad choice I hope. I just do not want it to die by making it a unmaintained plugin because it is a joy working with Ebean! But remember this topic starts with the sentence: The Ebean project looks to be inactive.
Well, that is not the case anymore, so why the Play Ebean is still so far behind? Why not upgrading it? Obviously I am not able to upgrade it otherwise I would love to.

@bachi76

This comment has been minimized.

Copy link

commented Mar 2, 2014

@bthule @adis-me I fully agree the the JPA query API is very ugly - we omit it completely and use EasyCriteria: http://uaihebert.com/easycriteria-2-0-jpa-criteria-should-be-easy/ - with this, you get a very flexible, readable query syntax and at the same time all JPA advantages.

@oeil

This comment has been minimized.

Copy link

commented Mar 7, 2014

@bachi76 Easycriteria looks nice, however I would rather use QueryDSL in production (http://www.querydsl.com/) which provide similar ease of query building for JPA. The project is well supported and will last for sure where easycriteria is uncertain.

We've been using JPA (Hibernate and EclipseLink impl) for years now on different kind of projects and discovered Ebean along with Play Framework, since then I became a fan of Ebean for its simplicity (modeling, querying, flexibility, stateless, setup) compared to JPA.

The issue with Ebean today is its lack of up-to-date documentation and consistency with the web site, this leads users to confusions. The good news is that they are working on it. @dominicwilliams @rbygrave Thanks guys for your good work.

I also vote to not set JPA as the default DB provider.

@tuxBurner

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2014

Keep Ebean PLEEAAASSE :)
It is so much natural to use it in Play. Every developer which i met and told him to take a look at Ebean instead of using JPA was thanking me afterwards. IMHO it is much easier to use and to understand than the JPA stuff, just the finder it self is so awesome.

@huntc

This comment has been minimized.

Copy link
Contributor Author

commented Mar 7, 2014

I've changed the title of this issue as it has been ruffling too many feathers! The intent is to factor out Ebean and anorm so they may stand alone and thrive independently of Play. Over time jpa and slick will likely become our default offering from play but not at the expense of Ebean and anorm.

Please note that this refactoring exercise isn't confined to Ebean and jpa and that other parts of play may be factored out so they can thrive. As an example all of the js related functionality will live outside of Play in 2.3.

I hope that this comment puts any concerns to rest.

@dominicwilliams

This comment has been minimized.

Copy link

commented Mar 8, 2014

I actually spent 3-4 weeks on a new (complex) project coding with
EclipseLink (JPA 2.0), JOOQ and Ebean in parallel. Ebean won for us hands
down.

There are reasons that usage of Ebean within Play has been problematic
historically, including asking people to derive from Model which screws you
up when you want to put your data entities in a separate jar and share
between lots of projects.

We just JPA Tools -> Generate Entities from Tables... (Dali) to quickly
create entity classes. These are then compiled into our data entity jar
which performs Ebean enhancement as a Maven build step. The Jar is shared
across multiple projects and works very well. Generally speaking,
performance is good because of the nice caching model, ability to do
partial fetches, we have the control to do what we want, we can easily
write & integrate raw SQL and the code looks 100% better.

Ebean documentation has been very lacking and I started a project to fix
this with a new website. Although I've been pulled off onto other things
for the moment, other people are now working on pulling he documentation
onto forks (if you are reading this and would like to join the effort,
please contact me asap). An Ebean 4.0.0 is in the works although not on
Github yet.

http://dominicwilliams.github.io/ebean-website/

On Fri, Mar 7, 2014 at 4:09 AM, Seppel Hardt notifications@github.comwrote:

Keep Ebean PLEEAAASSE :)
It is so much natural to use it in Play. Every developer which i met and
told him to take a look at Ebean instead of using JPA was thanking me
afterwards. IMHO it is much easier to use and to understand than the JPA
stuff, just the finder it self is so awesome.

Reply to this email directly or view it on GitHubhttps://github.com//issues/1518#issuecomment-37018572
.

@jroper jroper modified the milestone: 2.3.0 Mar 27, 2014

@jroper

This comment has been minimized.

Copy link
Member

commented Mar 27, 2014

Closing this because the top level issue I think is too broad (talks about ebean, slick, anorm, etc). Individual issues can be created when or if we decide to do them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.