Discussions

News: Ebean ORM v2.2.0 Released - Adds "Query Joins" and batch lazy

  1. Query joins are an additional option to "fetch joins" and lazy loading. With Ebean v2.2.0 you can specify a join to be a query join and use a second SQL query to build the resulting object graph. http://www.avaje.org/ebean/introquery_joinquery.html There are a number of cases where this is useful as a performance optimizationAbout Ebean ORM ---------------- - Uses JPA Annotations for mapping (@Entity, @OneToMany etc) - Easy to use Sessionless API (no merge, flush etc) - Lazy loading 'just works' - Automatic query tuning via "Autofetch" - LGPL license You can find more information about Ebean at www.avaje.org

    Threaded Messages (12)

  2. As a long time ORM (hibernate,ibatis, cayenne), I find Ebean quite impressive. Big kudos to the developers. Could someone explain the caching capabilities? If it has something equivalent to first and second level caches in Hibernate, I might just give this a spin for an upcoming project.
  3. Caching Capablities[ Go to top ]

    @han Yes, Ebean has both a level 1 and level 2 cache. In the documentation the level 1 cache is primarily referred to as the 'persistence context'. The user guide does cover the 'persistence context' and use of the level 2 cache in some detail. Cheers, Rob.
  4. Re: Caching Capablities[ Go to top ]

    @han

    Yes, Ebean has both a level 1 and level 2 cache. In the documentation the level 1 cache is primarily referred to as the 'persistence context'. The user guide does cover the 'persistence context' and use of the level 2 cache in some detail.


    Cheers, Rob.
    Good stuff. It even seems to work :-p
  5. Nice but ...[ Go to top ]

    Yet another fine OS project seriously lacking documentation. For example, there is mention in the user guide that there is Spring transaction support as of version 2.0. The current version is v2.2 and there is no information in the user guide as to how to achieve this integration. Brilliant idea but I won't be surprised if this project doesn't attract the following it deserves and ultimately ends up like the many failed OS projects. Jan
  6. Spring Transactions[ Go to top ]

    @Jan That's a fair point Jan. Especially in regards to documentation it sometimes takes a proverbial nudge to get things up to scratch and wrt the spring transaction integration its not up to scratch yet - so thanks for the nudge :) I have only had good comments on the rest of the documentation though so it can't be all bad :) WRT Spring Transactions: I do know that we have some outstanding issues we wanted to clarify with the spring folks wrt using their existing transaction managers. Specifically they don't currently have any support for registering listeners (to listen for begin/commit/rollback events) so that limits us (Ebean with Spring txns) in a couple of ways and we'd like to clarify the best approaches to take. Everyone is busy so this has taken us longer than we'd like to get clarification. In the meantime perhaps the best thing would be to fire specific questions at the Ebean google group and we'll do our best. Thanks, Rob.
  7. Spring Transactions[ Go to top ]

    @Jan I forgot to mention the obvious which is that the spring module comes with a small example app configuring Ebean using Spring. Aka the example uses the EbeanServerFactoryBean that implements Spring FactoryBean. ... just in case you haven't seen that.
  8. Re: Nice but ...[ Go to top ]

    You need to learn to read code as documentation, Jan. There are too many good open source projects out there with very lacking documentation. Because they focus on getting things done. I refuse to ignore these just because of docs. The projects with a LOT of documentation tends to have WRONG and outdated documentation. You simply need a lot of people to have both great docs and great impl's. Hibernate provides a fantastic amount of great and current documentation (even books), but it's not really fair to compare these projects. Hibernate has a lot of people and some of the core ones are unhumanly productive.
  9. static method EBean.find??[ Go to top ]

    Wait, is that a static method EBean.find? http://www.avaje.org/ebean/introquery.html What about good OO design? I couldn't even imagine using an ORM with a static method right at the heart of its API like that. What if I want to write a unit test on a class of mine that calls this method? What if I have two different modules in my application that each need to have their own ORM session?
  10. Re: static method EBean.find??[ Go to top ]

    Okay, I take it back! Looking a little more closely, I see that these static methods are just proxy methods for a default EbeanServer (page 8 of user guide). I'm still not sure if I like this though. Yes, it helps make it easy to get up and running quickly. But I can already imagine slogging through a junior developer's code and removing all the static method invocations. Probably not that big a deal; probably the ease of use is worth the tradeoff.
    Wait, is that a static method EBean.find?

    http://www.avaje.org/ebean/introquery.html

    What about good OO design? I couldn't even imagine using an ORM with a static method right at the heart of its API like that.

    What if I want to write a unit test on a class of mine that calls this method? What if I have two different modules in my application that each need to have their own ORM session?
  11. Re: static method EBean.find??[ Go to top ]

    In regards to Ebean (the singleton proxy object) you don't have to use it *AT ALL*. Yes, it is there as a convenience and yes it does just proxy through to the 'default' EbeanServer. Alternatively you can programmatically create an EbeanServer via EbeanServerFactory yourself. If you were in a Guice/Spring/DI environment you would more likely configure and construct an EbeanServer(s) programmatically (in spring you might use the EbeanServerFactoryBean)... and use Guice/Spring to inject the EbeanServer(s). So yes, you certainly do not need to use the Ebean "singleton proxy" object and in a Guice/Spring/DI environment you probably would not. However, it is convenient when you are not in a DI environment and mostly dealing with a single DataSource. For those wondering, there is one EbeanServer per javax.sql.DataSource. PS: I think you should get that junior to clean it up themselves - it would reinforce the lesson no? Cheers, Rob.
  12. my bad[ Go to top ]

    Thanks for your patient response Rob! A few days later I really began to regret my initial comment on this article. For one thing, I was making a major deal out of a minor issue. I've since had the time to read through the Ebean manual and I am very impressed. The design is clearly very carefully thought out, and the query language is 100x better than HQL! I still can not figure out how to get HQL to do what I want except in the simplest of cases. The Ebean query language is intuitive and looks much easier to use. The most exceptional part of it all is that Ebean seems to be the work of a single developer for the most part. It is missing some critical features (like optimistic locking), but a real tour de force! I'm really hoping this project picks up some momentum so I can use it in place of Hibernate on my next project!
  13. Optimistic locking[ Go to top ]

    Actually it has always had support for optimistic locking. It doesn't yet have support for pessimistic locking though. Perhaps that's what you meant.