Re: Hibernate
Re: Hibernate
- Subject: Re: Hibernate
- From: Joe Little <email@hidden>
- Date: Wed, 25 Feb 2009 10:16:19 -0800
I'll at least but in one one data point below.
On Wed, Feb 25, 2009 at 9:45 AM, Mike Schrag <email@hidden> 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.
This is actually accomplished with Grails and GORM. I was researching
it heavily, and it matches your description of being easier to do the
simpler things, but I too was concerned about the underlying caching
and stress on the DB. There is some heavier lifting that EOF appears
to do here. But Grails is the groovy equiv of Rails/ActiveRecord on
top of Hibernate. Better yet, it lets you pick a EO-like native
approach or still use Hibernate more directly if you choose.
>
>> 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