Re: Hibernate
Re: Hibernate
- Subject: Re: Hibernate
- From: Gustavo Pizano <email@hidden>
- Date: Wed, 25 Feb 2009 18:52:19 +0100
Sorry about last mail..
Lord had Spoken!! (I mean MS)
even I worked with Hibernate, it gave me hard times, but I didnt work
that much to have a valid opinion.
Gus
On 25.2.2009, at 18:45, Mike Schrag wrote:
While the tone of the emails does sound in favor of EOF, could you
please share some concrete instances and examples of why Hibernate
doesn't cut it for you?
I actually think Hibernate has quite a few very nice features (that
EOF should steal), not the least of which is a very large community
(harder to steal :) ). So a big caveat here is that I only know
Hibernate from reading about it and from friends who use it, and I
don't have any firsthand experience, but I'll at least try to
discuss the points conceptually.
1. the Session doesn't need to be tightly bound. unlike
EOEditingContext that's tightly bound to the EOObjectStoreCoordinator
I'm not exactly sure what you mean here, or what you the desired
features would be if you could "unbind" an EC from an OSC? You can
obviously just make an EC with a new instance of an OSC and have it
standalone, but I'd be curious to hear more about what kinds of
problems you're trying to solve.
2. it's easier to multi-thread and connection pool with Hibernate
I'm not sure this is NECESSARILY true ... I suppose it depends on
how you look at it, but for instance, http://blog.xebia.com/2009/02/07/hibernate-and-multi-threading/
basically shows that Hibernate has some of the same threading
complexities that EOF does with respect to sharing objects between
threads, at which point, you're really probably comparing using
multiple OSC's. I will definitely grant that EOF's snapshot cache is
both a blessing an a curse. I believe hibernate has a "snapshot
cache" (equivalent) as well, but that the default behavior is that
the cache goes away when the session goes away (which is typically
session-per-request in Hibernate as I understand it?), so there are
much fewer issues with cache freshness in exchange for default
behavior that hits the db more often. You can add a second level
cache to Hibernate, at which point, I imagine the issues are
identical (cache invalidation is cache invalidation -- no way around
it really). Hibernate is written with much better abstractions here,
though, in that you can rip out the backing layers and change their
behavior -- this is very hard to do in EOF, though something that
will hopefully be changed. I think one of the issues with WO/EOF is
that it's easy to do some really complicated things, but actually
kind of hard to do some easy things ... If you WANT to make an app
that has the behavioral characteristics of, say, Rails w/ routers
and controllers + EOF that behaves more like Hibernate or
ActiveRecord, you really have to work at it. I'd like to see some
more support for alternative use cases -- I sometimes feel like I'm
fighting EOF to do something that shouldn't be hard.
3. Hibernate validators are not too bad for basic validations
I've always felt that EOF should have more out-of-the-box model-
defined validation support (more than just "not null"). I don't know
how much I rank this as an EOF limitation or a Hibernate feature,
though, as both are sort of orthogonal to the core frameworks.
Wonder, for instance, could easily add nice default validators
without requiring any changes to EOF (and actually HAS a bunch of
this with Validity framework, but I'm not sure if anyone actually
uses it or what the state of it is), because EOF happens to have a
fairly clean design here. That said, out-of-the-box experience is
valuable -- that we could theoretically add it is still less cool
than that Hibernate just already has it built in.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden