I would agree.
The performance gain here should highlight caching while the other
points more closely align with reduction of development time.
On 08/07/2017 02:09 AM, andrea boriero wrote:
it looks really good to me, the only little doubt is related with
example in the "how Hibernate is useful" Performance subsection, the
example looks to me more appropriate for the "Developer time" subsection.
On 4 August 2017 at 21:09, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> wrote:
> Hi Steve,
> I read it and I have some the following suggestions:
> 1. For the Performance section, I'd add the transparent JDBC batch updates,
> the delayed connection acquisition, cacheable natural id fetching.
> 2. For the How does Hibernate compare to JPA section, I'd add a list of
> cool features Hibernate has to offer on top of JPA:
> - extended identifier generators (hi/lo, pooled, pooled-lo)
> - customizable CRUD (@SQLInsert, @SQLUpdate, @SQLDelete) statements
> - immutable entities (e.g. @Immutable)
> - versionless optimistic locking (e.g. OptimisticLockType.ALL,
> - support for skipping (without waiting) pessimistic lock requests
> - support for multitenancy
> 3. For the jOOQ part:
> I'm not sure about the "JDBC libraries" term. All data access
> build on top of JDBC. Maybe "SQL statement builder frameworks" or
> Record frameworks" are more suitable.
> Otherwise, it's a good addition to the Hibernate documentation.
> On Fri, Aug 4, 2017 at 6:46 PM, Steve Ebersole <steve(a)hibernate.org>
>> I spent some time this a.m. working on changes to the ORM FAQ page:
>> Let me know what you think. It's still not "done", but further
>> I am trying to avoid "usage" FAQ entries. These should be more
>> project FAQs. We should decide how/where we want to handle "usage"
>> if at all.
>> hibernate-dev mailing list
> hibernate-dev mailing list
hibernate-dev mailing list