Discussions

News: Ebean ORM v1.0.0 Released - adds @Transactional support

  1. Goto http://www.avaje.org/ebean/introtrans_transactional.html For an example/explanation of using @Transactional Goto http://www.avaje.org/ebean/introtrans_txrunnable.html For an example/explanation of using TxRunnable and TxCallable which are the programatic equivalent. Note: To use @Transactional you need to use "Enhancement" via either IDE Plugin, Ant task or javaagent (as opposed to using the "Subclassing" approach). Note: Enhancement vs Subclassing is discussed in the Ebean user guide with a related discussion of property vs field access. Enjoy, Rob.

    Threaded Messages (7)

  2. Looks good[ Go to top ]

    Rob, If you can make Ebean a Fedora for the JPA I'm going to be a user. Just keep the builds stable. Great job.
  3. Non table class mapping[ Go to top ]

    Persist ORM (http://code.google.com/p/persist/) allows custom queries with no matching java type, providing however, automatic mapping on the fly. This is really desirable many times in my experience. Does Ebean have such a feature? @NoTable public class MyClass { String myfield; } ... Persist p = new Persist(connection); MyClass mc = p.read(MyClass.class, "... custom sql .."); System.out.println(mc.myField); // done ... Will it work with your raw jdbc transaction demarcation? Thanks.
  4. custom queries with no matching java type
    Ebean has @SqlSelect annotation. With this you can then dyanamically add to the where/having/order by clauses etc. This is designed for reporting type beans that are based on arbitrary sql. Ebean also has MapBean's which are hashmap like and don't use any mapping at all (based on tables and columns directly). These are good for completely dynamic requirements. So, its a question of whether either of these approaches do what you need. Its a question of how dynamic your sql is but if you are using a bean then I'd guess @SqlSelect is what you want to try.
    raw jdbc transactions
    My next task is to integrate into Spring Transaction demarcation. With that I'll likely end up exposing a method to create a Ebean transaction given an external java.sql.Connection - which is what I suspect you want (and not part of the current v1.0.0 api). With Ebean you can specify your own DataSourceFactory to create the DataSource (or use JNDI or the built in DataSource). You want this when you want Ebean to create transactions for you (implicit or explicit). So that said, can you expand a bit more on what you are looking for here?
  5. Thanks[ Go to top ]

    Rob, You answered my question. I will read the docs and use the forums I guess.
  6. Thanks for sharing it with us. Enjoyed reading the up-to-the -point documentation. But , why should one use EBean ? Especially when you already have mature tools like Hibernate. I did not find EBean particularly easy (Easy to me is being able to create queries with out hand written code) and do you have plans to integrate with cache systems like EhCache? -Nagraj
  7. Why Ebean[ Go to top ]

    But , why should one use EBean ?
    The major difference is that Ebean follows a "sessionless" approach (compared with Hibernate/Toplink/JPA). So there is no merge/flush etc (no concept of attached / detached beans). Ebean query language supports "Partial Objects" for *ANY* node in the object graph. JPQL does NOT support this and IMO its hard to see JPQL doing so due to the design of the their select statement. Automatic query tuning via Autofetch is a "first class citizen" in Ebean. Its available as a plugin feature for Hibernate but not on any other ORM's that I know. IMO this is a very important feature for ORM.
    I did not find EBean particularly easy (... without hand written code).
    Not sure but I think that means you prefer @NamedQueries with named parameters for example? If so then yes you can use named queries. The other thing here (from my perspective) is that Autofetch changes the query landscape in that you no longer need to specify joins at all - just leave it to Autofetch to tune the query. Your queries just then specify the "root type" and your predicates/criteria order by and limits.
    integrate with cache systems like EhCache?
    Yes, it is on the plan. Someone else asked for this a few weeks ago as well so you are not alone in wanting this.
  8. Why Ebean?[ Go to top ]

    But , why should one use EBean ?
    The major difference is that Ebean follows a "sessionless" approach (compared with Hibernate/Toplink/JPA). So there is no merge/flush etc (no concept of attached / detached beans). Ebean query language supports "Partial Objects" for *ANY* node in the object graph. JPQL does NOT support this and IMO its hard to see JPQL doing so due to the design of the their select statement. Automatic query tuning via Autofetch is a "first class citizen" in Ebean. Its available as a plugin feature for Hibernate but not on any other ORM's that I know. IMO this is a very important feature for ORM.
    I did not find EBean particularly easy (... without hand written code).
    Not sure but I think that means you prefer @NamedQueries with named parameters for example? If so then yes you can use named queries. The other thing here (from my perspective) is that Autofetch changes the query landscape in that you no longer need to specify joins at all - just leave it to Autofetch to tune the query. Your queries just then specify the "root type" and your predicates/criteria order by and limits.
    integrate with cache systems like EhCache?
    Yes, it is on the plan. Someone else asked for this a few weeks ago as well so you are not alone in wanting this.