How mature is Ebean or Siena? [closed]

Question

In the last time I heard a lot of complaining about Hibernate. And indeed I have some painful experiences with Hibernate too. So I read about Ebean and Siena.

Both have interesting approaches. Unfortunately, database access layers are very easy to write, but if your project grows and you have to handle great database-tables, you know if they are good or not. So it's really difficult to evaluate such a tool. Hibernate is well known and you could be sure that you can solve your problem with it. Sometime you need to learn a lot, but you can solve it.

How is it with Ebean? Are there any real world applications? Which databases are supported? Is it reliable?

After searching a little bit more I see that there are a lot more ORM-frameworks, so is there at least one reliable one?

Koenraad

Could you add some specifics as to what issues you encountered with Hibernate? That will help us eliminate ORM frameworks with the same limitations. – Crispen

Well Hibernate become difficult for batchjobs, where you made a lot of write operations. Furthermore Hibernate has often some surprising effects, for example, if you have create or change an object it will be saved automatically. To make it clear, Hibernate is a good reliable framework, but it's complex and complicated. If you a hibernate-expert it's really fine, but otherwise you can sometimes loose a whole developer day by trying to understand the behavior. Siena and Ebean promise to be simper (which is easy to prove) and reliable too (which no one ones to confirm). – Koenraad

Answer 1

Rob (Ebean Committer) here.

Ebean is about 4+ years old now. I would say it is fairly mature now. The supported DB's include Oracle, MySql, Postgres, H2 and SQL Server (and recently SQLite). Ebean is doing stuff that other ORM's are not such as Autofetch (automatic query tuning) so I'm not how that fit's into a 'maturity rating'. IMO the Ebean community is relatively small though so you probably need to hit the Ebean google group to engage them.

Any real world applications? Yes, but you are best to ask the Ebean community about that really. Certainly there is good support for batch processing (batch size, turn of cascading persist for a transaction etc) and large query support that I don't see in JPA etc (you might get something similar with Hibernate's Sessionless support).

Hopefully this might answer some small parts of your question anyway.

Cheers, Rob.

Safier

Thanks this was indeed a answer with helps. – Koenraad

Hi Rob, I see your maintaining the repositories on github, and appreciate the high utility of Ebean, but I'm having trouble finding up to date documentation. The stuff on avaje.org seems to be pretty ancient. Are there any recent Java-docs or guides anywhere? – Kidwell

@area5one The docs are WIP right now - you can see the current state at: ebean-orm.github.io That is far from complete but over the next month I'll look to complete the new docs/website. – Safier

@Rob Oh nice, this looks promising and gives confidence using the libraries. I've been enjoying Ebean so far so keep up the good work! – Kidwell

Answer 2

I'm currently a developer of Siena but not since very long. Let me explain why I became a developer on this project? I went to Siena because I wanted to use Play+GAE and Siena appeared to be a good start for GAE DB and I really wanted to avoid JDO/JPA. Then, I began to really appreciate Siena for its straightforward, light and easy approach and so simple APIs. It doesn't pretend to be the all-in-one abstraction layer like JDO and the greatest standard DB API like JPA. It really made me think of DB APIs from Python/Ruby and it really fits my point of view: I want a simple DB API which allows me to solve the great majority of my problems and when I have a more complex problem, I will use the lower layer APIs but certainly not an abstraction layer such as hibernate.

The possibility to make my code work on GAE DB or JDBC was also a good aspect. Once again, Siena doesn't pretend to provide exactly the same things in both worlds because SQL and NoSQL are not really compatible (but ORM is neither really compliant to SQL model :) ). But once again, it is quite practical to be able to rely on the same APIs in several DBs.

Finally, the library is ONE jar and you don't have to retrieve the whole universe to use it.

So, I became progressively a committer on Siena because I wanted to take part of this nice little adventure. Now siena team is working on a new version keeping the same simple APIs, bringing new interesting features and really improving all the backend code to make it even easier to extend for new DB support. Siena is a pragmatic API driven by user experiences and that's why I like it ;)

Pascal

Excellent

Thanks for sharing your experience, even if it doesn't show how mature it is. What I don't understand is why I can't switch between GAE and JDBC? I thought this was the great benefit of Siena. I mean otherwise it looks more clever to use specific "ORM-Mapper". – Koenraad

I never told that you can't switch between GAE and JDBC with Siena :D... You CAN switch and as you said, this is one of the great benefit of Siena. But we don't say you can ALWAYS switch between both because everything is not possible between SQL and NoSQL. Sometimes, you must design your models specifically for NoSQL or for SQL to be efficient... We don't pretend to solve all the problems between NoSQL and SQL because it would be a lie. But in the great majority of cases, the switch will work without any problem. – Excellent

Concerning the maturity, I'm not really the right person as I'm coding for Siena for the time being :)... But I know people use it in production and they chose Siena against JDO/JPA or other stuff in order to have a very simple API with a thin layer between their code and the DB... What's sure is that the code is very small, you only need one jar and the learning curve is very short... We are currently cleaning the code/design very carefully and implementing lots of tests so I think the quality of Siena will grow and grow... Don't hesitate to talk directly to siena group if you need anything! – Excellent

in my experience with play framework and GAE, going with JPA is a dead end, as soon as you need to map some kind of relation it simply shows it's limits... moreover, on play's gae module page, they recommend siena for gae development: playframework.org/documentation/1.0/gae – Medeah

Answer 3

We've had really great experience with MyBatis, which is not an ORM per se, but another class of persistence manager, an SQL Mapper. Using it you start with SQL statements and direct it on how to map result rows into POJOs. It's conceptually easy to understand and tune with not much magic going on inside. It's ideal if you are comfortable with SQL or need to work with an established schema.

Its

Yes I know, I worked with iBatis before and I think it's reliable. The limitations is the missing abstraction from database-system. If you must support multiple database-systems like Oracle, DB2, Postgres and H2 frameworks like Hibernate are really useful. – Koenraad

Answer 4

Besides Ebean and Siena:

You can try JIRM which is focused on CRUDing immutable objects (yes I'm the author).

There is also jOOQ and Joist.

I feel that JIRM minimizes the number of DTO's because the domain objects are immutable and do not inherit, implement and/or are not "enhanced/instrumented". Such is not the same with Siena and Ebean.

Also because the objects are Immutable there is more of a focus on per column updating instead of the whole object which makes more sense given today's AJAX interfaces (compared to the old POST the whole bean model).

Warmedover

Answer 5

What about using EB3, with for instance JBoss (www.jboss.org)?

Yore

Well I search for a simple solution. A JEE-enviroment doesn't fit this. – Koenraad