Factor out ebean from Play Java, factor out anorm and use JPA and Slick #1518
Comments
|
+1
|
|
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. |
|
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. |
|
Hi @mandubian re slick, just looking forward in time, possibly end of year. :-) |
|
Hi, @huntc , How about play-slick? I am going to use it with play 2.2. |
|
I have also recently adopted play-slick on a new project with play 2.2. |
|
Yes, I think play-slick makes sense. Need to evaluate further of course. |
|
Any hope of extracting anorm to its own project? Be very helpful to those of us committed to it. |
|
That's a good suggestion @bigjason - thanks |
|
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. |
|
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? |
|
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. |
|
I am not sure if anorm has a life or future of its own. |
|
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) |
|
"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 |
|
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. |
|
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. |
|
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. |
|
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 **
** Ebean development **
** Ebean advantages **
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.
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 |
|
@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. |
|
@seantbrady thanks if you have any particular views on information or On Thu, Nov 14, 2013 at 1:12 PM, seantbrady notifications@github.comwrote:
|
|
At the end of the day, there are two tasks involved in this issue:
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. |
|
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. |
|
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
However, the story had a happy ending as i discovered scala and slick !! |
|
seems like ebean is not dead 11 Sep 2013 - Release 3.2.4: Bug fixes |
|
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. |
|
ebean is a plugin, and Play is independent from the database framework. |
|
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. |
|
@jensjaeger +1, that would be great, indeed! |
|
uh @jensjaeger +1 |
|
Indeed it would be great to have a Model helper |
|
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... |
|
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 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 👎 |
|
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:
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. |
|
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 -----
|
|
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. |
|
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. |
|
@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. |
|
@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. |
|
Keep Ebean PLEEAAASSE :) |
|
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. |
|
I actually spent 3-4 weeks on a new (complex) project coding with There are reasons that usage of Ebean within Play has been problematic We just JPA Tools -> Generate Entities from Tables... (Dali) to quickly Ebean documentation has been very lacking and I started a project to fix http://dominicwilliams.github.io/ebean-website/ On Fri, Mar 7, 2014 at 4:09 AM, Seppel Hardt notifications@github.comwrote:
|
|
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. |
and others
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.
The text was updated successfully, but these errors were encountered: