You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Joel Trunick <jo...@webifysolutions.com> on 2005/01/20 17:09:49 UTC
RE: Persistence: JDO vs. Hibernate vs. Cayenne
In my experience Hibernate is nowhere close to say TOPLink in terms of
maturity. If you want ironclad support and the most complete
functionality go with TOPLink.
Hibernate's HQL is quite usable, but the Query API which in my opinion
should be a fundamental part of any OR layer is not usable at this
point. Its lacking fundamental features such as sorting on objects not
returned in query, and doing a simple count(!) and unbelievably not
planned in any upcoming version(!).
You are remiss not to check out Cayenne. Tapestry is the Java version of
Apple WebObjects, and Cayenne is essentially the Java version of Apple's
EOF, which goes hand-in-hand with WebObjects (from what I understand).
Cayenne has a solid Query API, and it is more gracious in handling lazy
loading from my understanding (unfortunately, I went with Hibernate
myself).
Hibernate is usable enough, but I wouldn't want to map to a legacy DB
with it. If you do use it, only use it with Spring, which cleans up
Hibernate's exception (non)-framework.
But try checking out Cayenne, it may prove to be a better choice
particularly with Tapestry.
Joel
-----Original Message-----
From: Patrick Yip [mailto:yipp@ICG.com]
Sent: Wednesday, January 19, 2005 6:32 PM
To: Tapestry users
Subject: RE: Persistence: JDO vs. Hibernate
Here are some criticisms that I just received from a commercial JDO
vendor regarding Hibernate. Since I'm still trying to figure out
Hibernate, I'm wondering if these criticisms are fair. Please comment if
possible. I greatly appreciate it.
Here they are:
*Does not provide a mechanism for mapping object-relational models that
are vastly different from the database's relation model.
Does not provide a mechanism for mapping from a DOM object to the
database directly. Need to create an object-relational model first. This
implies an additional step in persisting the data.
Seems to have its own database transaction and session management
framework which does not provide for easy integration into the Java
services framework. This framework does not allow the transaction
management model to go over two databases.
Not a very refined tool in terms of user interfaces and tools to make
the development task easier.
The following list highlights some of the deficiencies of Hibernate
pointed out by past evaluators:
Interfact for integration
Hibernate requires more intrusion into application than JDO
Hibernate can require database specific code i.e., Identity Attributes
Does require specific coding style, JavaBeans, Collection Interfaces,
etc.
Might need some code to track some state changes
Mapping Objects to Tables
No "out of the box" visual tools
Third party, but incomplete and don't support most data-model patterns
No visual support for all modes (forward, reverse, meet-in-the-middle)
Integrated deployment architecture
No "out of the box" clustered cache and no query cache in cluster
No built-in connection pooling. No remote client access. Incomplete
APIs for decoupling.
Lifecycle management of objects
Weak callback support
Weak object management outside of a transaction
Weak lazy loading
Object caching, distribution
Optimistic transaction support
Only 3rd party connection cache (EHCache)
No out of the box clustered caching
No query caching in a clustered environment
No pre-load caching options
Performance tuning, monitoring, and debug-ability
CGLIB runtime proxies and / or reflection
No visual tools to configure monitoring or debugging
Limited FetchGroup support
ROI (Build vs. Buy)
Free at first
Does it really matter if the tool is incomplete in capability?
Need support? Need tools? Release schedule reliance?
-----Original Message-----
From: Kurtis Williams [mailto:kwilliams@mshare.net]
Sent: Wednesday, January 19, 2005 4:25 PM
To: Tapestry users
Subject: RE: Persistence: JDO vs. Hibernate
I'll try to post it up on my blog when I get a moment. I'll have to
whittle it down a bit since it's got a whole lot of other cruft in it!
:) I think you'll find that if you do it properly, it won't even seem
like you're using a non-object oriented approach. As for the select on
each request, caching can help with that.
-----Original Message-----
From: Vjeran Marcinko [mailto:vjeran@tis.hr]
Sent: Wednesday, January 19, 2005 3:57 PM
To: Tapestry users
Subject: Re: Persistence: JDO vs. Hibernate
Hi Kurtis.
Yes, I'm definetly interested in seeing your ModelListPage,
EditModelPage,
and
EditDetailPage, though I know it is the way that is described in
"Hibernate
In Action" as "a hard way" with IDs, maybe just masked to look OO.
Thing is that each strategy has it's pros and cons, but one thing that
I'm
especially appreciate is *simplicity*, and passing IDs around seems the
simpliest solution for me, and for my colegues that could jump in to
project. Yes, it maybe requires one sql SELECT more during each request
to
load new instance, yes, it's maybe not OO, but hey, you don't have to
worry
about back-button, about HttpSession size, reattaching, putting fancy
ServletFilters, putting hibernate sessions in HttpSession and marking
start/end of user-transactions etc... and versioning through checking
version field manually requires just one line of code that it isn't an
issue.
Thanx,
Vjeran
----- Original Message -----
From: "Kurtis Williams" <kw...@mshare.net>
To: <ta...@jakarta.apache.org>
Sent: Wednesday, January 19, 2005 6:18 PM
Subject: RE: Persistence: JDO vs. Hibernate
When I was developing my current system on top of Hibernate and Tapestry
I desperately wanted to use the "OO" approach. My reasoning was exactly
what you mention: Tapestry deals with objects and Hibernate is capable
of working with detached objects. I tried for a month to make it work
the way I wanted and I'm convinced that now that I know more about
Tapestry that I could make it work properly.
I also try to avoid putting too much in the session. And even though
Hibernate is capable of working with detached objects, it complicates
matters significantly due to whole-object-graph-serialization, lazy
instantiation, and multiple instances of entities trying to be
associated with a single session.
In the end, I found that I could simply use ID's and still work with
Tapestry in an "OO" way. What I did is create a series of abstract page
classes that deal with the ID for me. For example, I have an
EditDetailPage that accepts and object as a property/parameter. It's
smart enough to create a persistent ID property "on the fly" out of the
Hibernate object. The page knows enough about the object and its
services to recreate the object when page logic asks for it, just using
the ID. All this is transparent to the page's logic, so even though I'm
working with ID's, you'd never know it if you looked at one of my pages.
I found that this approach prevented many of the problems I mentioned
earlier.
Another approach I've thought of since is to embed the hibernate object
into the page as a hidden field. Since Tapestry can save whole objects
as hidden fields through the use of a data squeezer, the hibernate
object could be passed down with the page and then re-attached on
submit.
One thing I didn't like about this approach is that I wanted my Web tier
to be weakly coupled with my service tier, and my service tier to be
weakly coupled to my persistence tier. In order to re-associated
detached objects with Hibernate, I had to add an "attach" method that
called through the service and DAO tiers to call session.update() or
session.lock() to re-associated the detached instance with Hibernate.
Since not ever persistence scheme out there has an "attach" mechanism, I
viewed this as an unacceptable coupling of my front with my back. The
ID approach doesn't suffer from this problem because you're working with
different instances on each request.
The Hibernate-Session-Per-User-Transaction pattern gets around this
problem because the same session is used for the entire user
interaction. The thing I didn't like about this pattern was the fact
that a Hibernate session had to be associated with the user's
HttpSession (and is disconnected/connected on each request). The other
problem for me was that I had to wire up Tapestry's Engine or Visit to
be Hibernate-aware in order for this pattern to work. Since my
architecture is back-end agnostic, this was an unacceptable coupling of
back-end technology to front-end technology. (Open Session-In-View also
violates this, but since it's isolated to a single Servlet Filter and
it's transparent to the code, I can live with it!) If my project were
smaller and I didn't have a service and persistence tier behind the
Tapestry web tier, I think I'd prefer the session-per-user-transaction
strategy.
If you're interested in seeing how my ModelListPage, EditModelPage, and
EditDetailPage work, post and I'll give you the run-down.
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17.1.2005
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Persistence: JDO vs. Hibernate vs. Cayenne
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Well, I would encourage to use Hibernate without Spring (in fact I
encourage not to use Spring at all), same easiness of Hibernate( iBatis,
or even plain JDBC) use can be achieved with HiveMind or very simple
CGLib enhancer.
Check it on my site:
http://kgionline.com/articles/aop_1/aop1.jsp or example with iBatis
http://kgionline.com/xflow2/doc/xflow2/code_tricks.html
similar interceptor can be easily done with HiveMind (
http://kgionline.com/articles/aop_1/aop_perf.jsp )
Joel Trunick wrote:
>In my experience Hibernate is nowhere close to say TOPLink in terms of
>maturity. If you want ironclad support and the most complete
>functionality go with TOPLink.
>
>Hibernate's HQL is quite usable, but the Query API which in my opinion
>should be a fundamental part of any OR layer is not usable at this
>point. Its lacking fundamental features such as sorting on objects not
>returned in query, and doing a simple count(!) and unbelievably not
>planned in any upcoming version(!).
>
>You are remiss not to check out Cayenne. Tapestry is the Java version of
>Apple WebObjects, and Cayenne is essentially the Java version of Apple's
>EOF, which goes hand-in-hand with WebObjects (from what I understand).
>
>Cayenne has a solid Query API, and it is more gracious in handling lazy
>loading from my understanding (unfortunately, I went with Hibernate
>myself).
>
>Hibernate is usable enough, but I wouldn't want to map to a legacy DB
>with it. If you do use it, only use it with Spring, which cleans up
>Hibernate's exception (non)-framework.
>
>But try checking out Cayenne, it may prove to be a better choice
>particularly with Tapestry.
>
>Joel
>
>
>
>-----Original Message-----
>From: Patrick Yip [mailto:yipp@ICG.com]
>Sent: Wednesday, January 19, 2005 6:32 PM
>To: Tapestry users
>Subject: RE: Persistence: JDO vs. Hibernate
>
>Here are some criticisms that I just received from a commercial JDO
>vendor regarding Hibernate. Since I'm still trying to figure out
>Hibernate, I'm wondering if these criticisms are fair. Please comment if
>possible. I greatly appreciate it.
>
>Here they are:
>*Does not provide a mechanism for mapping object-relational models that
>are vastly different from the database's relation model.
>
>Does not provide a mechanism for mapping from a DOM object to the
>database directly. Need to create an object-relational model first. This
>implies an additional step in persisting the data.
>Seems to have its own database transaction and session management
>framework which does not provide for easy integration into the Java
>services framework. This framework does not allow the transaction
>management model to go over two databases.
>Not a very refined tool in terms of user interfaces and tools to make
>the development task easier.
>
>
>The following list highlights some of the deficiencies of Hibernate
>pointed out by past evaluators:
>
>
>Interfact for integration
>
>Hibernate requires more intrusion into application than JDO
>Hibernate can require database specific code i.e., Identity Attributes
>Does require specific coding style, JavaBeans, Collection Interfaces,
>etc.
>Might need some code to track some state changes
>Mapping Objects to Tables
>
>No "out of the box" visual tools
>Third party, but incomplete and don't support most data-model patterns
>No visual support for all modes (forward, reverse, meet-in-the-middle)
>Integrated deployment architecture
>
>No "out of the box" clustered cache and no query cache in cluster
>No built-in connection pooling. No remote client access. Incomplete
>APIs for decoupling.
>Lifecycle management of objects
>
>Weak callback support
>Weak object management outside of a transaction
>Weak lazy loading
>Object caching, distribution
>
>Optimistic transaction support
>Only 3rd party connection cache (EHCache)
>No out of the box clustered caching
>No query caching in a clustered environment
>No pre-load caching options
>Performance tuning, monitoring, and debug-ability
>
>CGLIB runtime proxies and / or reflection
>No visual tools to configure monitoring or debugging
>Limited FetchGroup support
>ROI (Build vs. Buy)
>
>Free at first
>Does it really matter if the tool is incomplete in capability?
>Need support? Need tools? Release schedule reliance?
>
>
>
>
>
>-----Original Message-----
>From: Kurtis Williams [mailto:kwilliams@mshare.net]
>Sent: Wednesday, January 19, 2005 4:25 PM
>To: Tapestry users
>Subject: RE: Persistence: JDO vs. Hibernate
>
>I'll try to post it up on my blog when I get a moment. I'll have to
>whittle it down a bit since it's got a whole lot of other cruft in it!
>:) I think you'll find that if you do it properly, it won't even seem
>like you're using a non-object oriented approach. As for the select on
>each request, caching can help with that.
>
>-----Original Message-----
>From: Vjeran Marcinko [mailto:vjeran@tis.hr]
>Sent: Wednesday, January 19, 2005 3:57 PM
>To: Tapestry users
>Subject: Re: Persistence: JDO vs. Hibernate
>
>Hi Kurtis.
>
>Yes, I'm definetly interested in seeing your ModelListPage,
>EditModelPage,
>and
>EditDetailPage, though I know it is the way that is described in
>"Hibernate
>In Action" as "a hard way" with IDs, maybe just masked to look OO.
>Thing is that each strategy has it's pros and cons, but one thing that
>I'm
>especially appreciate is *simplicity*, and passing IDs around seems the
>simpliest solution for me, and for my colegues that could jump in to
>project. Yes, it maybe requires one sql SELECT more during each request
>to
>load new instance, yes, it's maybe not OO, but hey, you don't have to
>worry
>about back-button, about HttpSession size, reattaching, putting fancy
>ServletFilters, putting hibernate sessions in HttpSession and marking
>start/end of user-transactions etc... and versioning through checking
>version field manually requires just one line of code that it isn't an
>issue.
>
>Thanx,
>Vjeran
>
>----- Original Message -----
>From: "Kurtis Williams" <kw...@mshare.net>
>To: <ta...@jakarta.apache.org>
>Sent: Wednesday, January 19, 2005 6:18 PM
>Subject: RE: Persistence: JDO vs. Hibernate
>
>
>
>When I was developing my current system on top of Hibernate and Tapestry
>I desperately wanted to use the "OO" approach. My reasoning was exactly
>what you mention: Tapestry deals with objects and Hibernate is capable
>of working with detached objects. I tried for a month to make it work
>the way I wanted and I'm convinced that now that I know more about
>Tapestry that I could make it work properly.
>
>I also try to avoid putting too much in the session. And even though
>Hibernate is capable of working with detached objects, it complicates
>matters significantly due to whole-object-graph-serialization, lazy
>instantiation, and multiple instances of entities trying to be
>associated with a single session.
>
>In the end, I found that I could simply use ID's and still work with
>Tapestry in an "OO" way. What I did is create a series of abstract page
>classes that deal with the ID for me. For example, I have an
>EditDetailPage that accepts and object as a property/parameter. It's
>smart enough to create a persistent ID property "on the fly" out of the
>Hibernate object. The page knows enough about the object and its
>services to recreate the object when page logic asks for it, just using
>the ID. All this is transparent to the page's logic, so even though I'm
>working with ID's, you'd never know it if you looked at one of my pages.
>I found that this approach prevented many of the problems I mentioned
>earlier.
>
>Another approach I've thought of since is to embed the hibernate object
>into the page as a hidden field. Since Tapestry can save whole objects
>as hidden fields through the use of a data squeezer, the hibernate
>object could be passed down with the page and then re-attached on
>submit.
>
>One thing I didn't like about this approach is that I wanted my Web tier
>to be weakly coupled with my service tier, and my service tier to be
>weakly coupled to my persistence tier. In order to re-associated
>detached objects with Hibernate, I had to add an "attach" method that
>called through the service and DAO tiers to call session.update() or
>session.lock() to re-associated the detached instance with Hibernate.
>Since not ever persistence scheme out there has an "attach" mechanism, I
>viewed this as an unacceptable coupling of my front with my back. The
>ID approach doesn't suffer from this problem because you're working with
>different instances on each request.
>
>The Hibernate-Session-Per-User-Transaction pattern gets around this
>problem because the same session is used for the entire user
>interaction. The thing I didn't like about this pattern was the fact
>that a Hibernate session had to be associated with the user's
>HttpSession (and is disconnected/connected on each request). The other
>problem for me was that I had to wire up Tapestry's Engine or Visit to
>be Hibernate-aware in order for this pattern to work. Since my
>architecture is back-end agnostic, this was an unacceptable coupling of
>back-end technology to front-end technology. (Open Session-In-View also
>violates this, but since it's isolated to a single Servlet Filter and
>it's transparent to the code, I can live with it!) If my project were
>smaller and I didn't have a service and persistence tier behind the
>Tapestry web tier, I think I'd prefer the session-per-user-transaction
>strategy.
>
>If you're interested in seeing how my ModelListPage, EditModelPage, and
>EditDetailPage work, post and I'll give you the run-down.
>
>
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Persistence: JDO vs. Hibernate vs. Cayenne
Posted by Derek Brown <ze...@yahoo.com>.
Hello,
Hibernate has had count support for some time now,
there are many ways to do it, as far as sorting
objects not returned from a query, I think this falls
outside the duties of ORM.
I think any past users of EOF will take to Cayenne,
but both frameworks have their merits, Cayenne has a
nice GUI Modeler. Hibernate uses POJO's, Cayennes
classes are aware they are being persisted.
Derek
--- Joel Trunick <jo...@webifysolutions.com>
wrote:
>
>
> In my experience Hibernate is nowhere close to say
> TOPLink in terms of
> maturity. If you want ironclad support and the most
> complete
> functionality go with TOPLink.
>
> Hibernate's HQL is quite usable, but the Query API
> which in my opinion
> should be a fundamental part of any OR layer is not
> usable at this
> point. Its lacking fundamental features such as
> sorting on objects not
> returned in query, and doing a simple count(!) and
> unbelievably not
> planned in any upcoming version(!).
>
> You are remiss not to check out Cayenne. Tapestry is
> the Java version of
> Apple WebObjects, and Cayenne is essentially the
> Java version of Apple's
> EOF, which goes hand-in-hand with WebObjects (from
> what I understand).
>
> Cayenne has a solid Query API, and it is more
> gracious in handling lazy
> loading from my understanding (unfortunately, I went
> with Hibernate
> myself).
>
> Hibernate is usable enough, but I wouldn't want to
> map to a legacy DB
> with it. If you do use it, only use it with Spring,
> which cleans up
> Hibernate's exception (non)-framework.
>
> But try checking out Cayenne, it may prove to be a
> better choice
> particularly with Tapestry.
>
> Joel
>
>
>
> -----Original Message-----
> From: Patrick Yip [mailto:yipp@ICG.com]
> Sent: Wednesday, January 19, 2005 6:32 PM
> To: Tapestry users
> Subject: RE: Persistence: JDO vs. Hibernate
>
> Here are some criticisms that I just received from a
> commercial JDO
> vendor regarding Hibernate. Since I'm still trying
> to figure out
> Hibernate, I'm wondering if these criticisms are
> fair. Please comment if
> possible. I greatly appreciate it.
>
> Here they are:
> *Does not provide a mechanism for mapping
> object-relational models that
> are vastly different from the database's relation
> model.
>
> Does not provide a mechanism for mapping from a DOM
> object to the
> database directly. Need to create an
> object-relational model first. This
> implies an additional step in persisting the data.
> Seems to have its own database transaction and
> session management
> framework which does not provide for easy
> integration into the Java
> services framework. This framework does not allow
> the transaction
> management model to go over two databases.
> Not a very refined tool in terms of user interfaces
> and tools to make
> the development task easier.
>
>
> The following list highlights some of the
> deficiencies of Hibernate
> pointed out by past evaluators:
>
>
> Interfact for integration
>
> Hibernate requires more intrusion into application
> than JDO
> Hibernate can require database specific code i.e.,
> Identity Attributes
> Does require specific coding style, JavaBeans,
> Collection Interfaces,
> etc.
> Might need some code to track some state changes
> Mapping Objects to Tables
>
> No "out of the box" visual tools
> Third party, but incomplete and don't support most
> data-model patterns
> No visual support for all modes (forward, reverse,
> meet-in-the-middle)
> Integrated deployment architecture
>
> No "out of the box" clustered cache and no query
> cache in cluster
> No built-in connection pooling. No remote client
> access. Incomplete
> APIs for decoupling.
> Lifecycle management of objects
>
> Weak callback support
> Weak object management outside of a transaction
> Weak lazy loading
> Object caching, distribution
>
> Optimistic transaction support
> Only 3rd party connection cache (EHCache)
> No out of the box clustered caching
> No query caching in a clustered environment
> No pre-load caching options
> Performance tuning, monitoring, and debug-ability
>
> CGLIB runtime proxies and / or reflection
> No visual tools to configure monitoring or debugging
>
> Limited FetchGroup support
> ROI (Build vs. Buy)
>
> Free at first
> Does it really matter if the tool is incomplete in
> capability?
> Need support? Need tools? Release schedule
> reliance?
>
>
>
>
>
> -----Original Message-----
> From: Kurtis Williams [mailto:kwilliams@mshare.net]
> Sent: Wednesday, January 19, 2005 4:25 PM
> To: Tapestry users
> Subject: RE: Persistence: JDO vs. Hibernate
>
> I'll try to post it up on my blog when I get a
> moment. I'll have to
> whittle it down a bit since it's got a whole lot of
> other cruft in it!
> :) I think you'll find that if you do it properly,
> it won't even seem
> like you're using a non-object oriented approach.
> As for the select on
> each request, caching can help with that.
>
> -----Original Message-----
> From: Vjeran Marcinko [mailto:vjeran@tis.hr]
> Sent: Wednesday, January 19, 2005 3:57 PM
> To: Tapestry users
> Subject: Re: Persistence: JDO vs. Hibernate
>
> Hi Kurtis.
>
> Yes, I'm definetly interested in seeing your
> ModelListPage,
> EditModelPage,
> and
> EditDetailPage, though I know it is the way that is
> described in
> "Hibernate
> In Action" as "a hard way" with IDs, maybe just
> masked to look OO.
> Thing is that each strategy has it's pros and cons,
> but one thing that
> I'm
> especially appreciate is *simplicity*, and passing
> IDs around seems the
> simpliest solution for me, and for my colegues that
> could jump in to
> project. Yes, it maybe requires one sql SELECT more
> during each request
> to
> load new instance, yes, it's maybe not OO, but hey,
> you don't have to
> worry
> about back-button, about HttpSession size,
> reattaching, putting fancy
> ServletFilters, putting hibernate sessions in
> HttpSession and marking
> start/end of user-transactions etc... and versioning
> through checking
> version field manually requires just one line of
> code that it isn't an
> issue.
>
> Thanx,
> Vjeran
>
> ----- Original Message -----
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org