Comments on: Evaluating EclipseLink 1.1 http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11 Everything beta Thu, 26 Jan 2012 21:31:17 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Samba Siva Rao http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11/comment-page-1#comment-439 Samba Siva Rao Tue, 08 Dec 2009 21:28:30 +0000 http://blog.newsplore.com/?p=981#comment-439 I have used Eclipselink to persist data to PostgreSQL, MySQL, and Oracle; and have never faced an issue that made me rethink my choice for persistence. Just because you are conversant with Hibernate, you felt using it easier, for some one who have used Toplink/eclipselink only would have felt the same with respect to Hibernate. There may be difference in the way a feature or two are implemented in either of the frameworks, since these are proprietary features and there has been no standard so far. Even Hibernate moved to the annotations way of doing things only after realizing that JPA is taking advantage of annotations; eclipselink may be slow on that bandwagon, but it will catch up. In fact, eclipselink 1.2 is a lot more easier to use than Hibernate is. When it comes to using Session Customizer on Tomcat, it is very obvious that Oracle users would not use Tomcat for deployment, and hence Toplink did not have a need to address this particular use case; but Eclipselink being open sourced, it would be better to simplify the deployment on tomcat. I have used Eclipselink to persist data to PostgreSQL, MySQL, and Oracle; and have never faced an issue that made me rethink my choice for persistence.

Just because you are conversant with Hibernate, you felt using it easier, for some one who have used Toplink/eclipselink only would have felt the same with respect to Hibernate.

There may be difference in the way a feature or two are implemented in either of the frameworks, since these are proprietary features and there has been no standard so far. Even Hibernate moved to the annotations way of doing things only after realizing that JPA is taking advantage of annotations; eclipselink may be slow on that bandwagon, but it will catch up. In fact, eclipselink 1.2 is a lot more easier to use than Hibernate is.

When it comes to using Session Customizer on Tomcat, it is very obvious that Oracle users would not use Tomcat for deployment, and hence Toplink did not have a need to address this particular use case; but Eclipselink being open sourced, it would be better to simplify the deployment on tomcat.

]]> By: blorg http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11/comment-page-1#comment-376 blorg Fri, 31 Jul 2009 23:54:20 +0000 http://blog.newsplore.com/?p=981#comment-376 I just had to migrate from Hibernate to EclipseLink due to a non-technical decision from above. The whole exercise was nothing but pain and now we have less functionality than before. The fun: - getting it to work with HSQLDB (used for all our unit tests) was pain - PersistenceUnitProperties.DROP_AND_CREATE does not work with postgresql so automatically re-creating the schema as required during development (Hibernate's "hibernate.hbm2ddl.auto", "create-drop" works of course) - documentation blows; the site and third party (look for EclipseLink/TopLink on Amazon and then try Hibernate) - lots of skilled Hibernate coders available; not so much for EclipseLink - online docs are peppered with Oracle specific code that can sneak in thus making your ORM choice locked to Oracle DB I am not an ORM expert but any time I have used Hibernate it just worked. For basic use I see zero benefit to EclipseLink so far. Maybe it is targeted for pro users with needs not covered in this discussion? I suspect the only people using EclipseLInk/TopLink are those using Oracle's frameworks/dev tools and Oracle DBs and it may be just great for that. But if you want to use other DBs and do things manually good luck. I just had to migrate from Hibernate to EclipseLink due to a non-technical decision from above. The whole exercise was nothing but pain and now we have less functionality than before. The fun:
- getting it to work with HSQLDB (used for all our unit tests) was pain
- PersistenceUnitProperties.DROP_AND_CREATE does not work with postgresql so automatically re-creating the schema as required during development (Hibernate’s “hibernate.hbm2ddl.auto”, “create-drop” works of course)
- documentation blows; the site and third party (look for EclipseLink/TopLink on Amazon and then try Hibernate)
- lots of skilled Hibernate coders available; not so much for EclipseLink
- online docs are peppered with Oracle specific code that can sneak in thus making your ORM choice locked to Oracle DB

I am not an ORM expert but any time I have used Hibernate it just worked. For basic use I see zero benefit to EclipseLink so far. Maybe it is targeted for pro users with needs not covered in this discussion?

I suspect the only people using EclipseLInk/TopLink are those using Oracle’s frameworks/dev tools and Oracle DBs and it may be just great for that. But if you want to use other DBs and do things manually good luck.

]]> By: mcahornsirup http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11/comment-page-1#comment-205 mcahornsirup Fri, 10 Apr 2009 15:10:23 +0000 http://blog.newsplore.com/?p=981#comment-205 Nice article. I worked with toplink and it was always a pleasure - especially together with the Netbeans IDE. Now, toplink is eclipselink and I tried to use it for an ORM to Postgres/PosGIS. It took me a whole 2 days to find the approoriate solution - a Session Customizer! I also googled for an hibernate solution and stumbled over a solution multiple times... somehow, I would love to use eclipselink, but it is really painful to use it. I really hope, that it will improve as it gains popularity through the eclipse project. Nice article. I worked with toplink and it was always a pleasure – especially together with the Netbeans IDE. Now, toplink is eclipselink and I tried to use it for an ORM to Postgres/PosGIS. It took me a whole 2 days to find the approoriate solution – a Session Customizer! I also googled for an hibernate solution and stumbled over a solution multiple times… somehow, I would love to use eclipselink, but it is really painful to use it. I really hope, that it will improve as it gains popularity through the eclipse project.

]]> By: Florin http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11/comment-page-1#comment-88 Florin Mon, 23 Mar 2009 13:34:17 +0000 http://blog.newsplore.com/?p=981#comment-88 You forgot about my remarks re query caching. Putting cache management into the code is backwards and a bad practice. JPA spec is JSR driven (220 for 1.0 and 317 for 3.0) so it's not about sharing a standard, it's about being compliant and EclipseLink will be the JPA 2.0 RI. Regarding using Tomcat&Spring vs. JEE container there's a ton of documentation on the internet that will tell you why the former combo is a winner. florin You forgot about my remarks re query caching. Putting cache management into the code is backwards and a bad practice.
JPA spec is JSR driven (220 for 1.0 and 317 for 3.0) so it’s not about sharing a standard, it’s about being compliant and EclipseLink will be the JPA 2.0 RI.
Regarding using Tomcat&Spring vs. JEE container there’s a ton of documentation on the internet that will tell you why the former combo is a winner.

florin

]]> By: Yannick Majoros http://blog.newsplore.com/2009/03/21/evaluating-eclipselink-11/comment-page-1#comment-86 Yannick Majoros Mon, 23 Mar 2009 08:40:16 +0000 http://blog.newsplore.com/?p=981#comment-86 Hi, You were fast to write an article on Eclipselink 1.1, just released. But I think you have to work more systematically to be able to give some useful advice. If you remove all non-standards queries problems, there isn't much left in your article. It seems ok to me that Eclipselink shares the jpa standard with other persistence providers, as Hibernate. Some Eclipselink extensions won't work on hibernate, it wouldn't be right to blame the latter. Other problems you mentioned were about the documentation and the weaving process. The documentation is complete, but I used to find it as awful as you seem to do. You just have to read a lot of thing before you understand it fully. It's just complete. What about weaving? It's just my advice, but using spring + tomcat looks to me like reinventing the wheel. What you are trying to do is adding what you miss from an application server into tomcat. Why? Using eclipselink would have taken 2 minutes on glassfish, I guess about the same on jboss. I don't quite understant why people are so afraid of app servers and are so willing do to the same things with spring. Regards Hi,

You were fast to write an article on Eclipselink 1.1, just released. But I think you have to work more systematically to be able to give some useful advice.

If you remove all non-standards queries problems, there isn’t much left in your article. It seems ok to me that Eclipselink shares the jpa standard with other persistence providers, as Hibernate. Some Eclipselink extensions won’t work on hibernate, it wouldn’t be right to blame the latter.

Other problems you mentioned were about the documentation and the weaving process.

The documentation is complete, but I used to find it as awful as you seem to do. You just have to read a lot of thing before you understand it fully. It’s just complete.

What about weaving? It’s just my advice, but using spring + tomcat looks to me like reinventing the wheel. What you are trying to do is adding what you miss from an application server into tomcat. Why? Using eclipselink would have taken 2 minutes on glassfish, I guess about the same on jboss. I don’t quite understant why people are so afraid of app servers and are so willing do to the same things with spring.

Regards

]]>