Rebased ORM6
by Sanne Grinovero
I've completed a rebase of Steve's latest ORM6 branch onto our latest ORM5
master, so to have it incorporate all latest bugfixes and performance
enhancements we recently developed on master.
To be more specific, this is a rebase of commit 'wip/sqm-jpa-types-sql-ast'
[2e002c73c6] onto 'master' [40b30fa099].
I'm pushing it as branch '6-rebased-August' to my own fork. (commit
[ec3a325fbc]).
I hope that anyone having some work in progress could cherry pick on top of
that :)
Also you probably want to push it somewhere else and give a more creative
name.
Steve: the last commit might need special attention.
I needed to review the SessionImpl#buildLockOptions method as there was a
conflict, but while trying to resolve it I realized the method was probably
not doing what it was supposed to, so I changed it - I think fixing
something odd but I might have misunderstood the intent, or thrown off by
some mistake during rebase. Would appreciate another pair of eyes on that
one as I definitely changed the semantics.
Thanks,
Sanne
6 years
Re: [hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo
by Gail Badner
I agree completely.
Thanks,
Gail
On Wed, Aug 28, 2019 at 5:09 AM Steve Ebersole <steven.ebersole(a)gmail.com>
wrote:
> In my opinion we really should not drop them unless we also write a
> conversion for the existing I'd values in the database to account for the
> new scheme the user picks. It's really just left there to allow these
> legacy databases keep working
>
> On Wed, Aug 28, 2019, 12:08 AM Gail Badner <gbadner(a)redhat.com> wrote:
>
>> Hi,
>>
>> The documentation for hibernate.id.optimizer.pooled.preferred says the
>> following:
>>
>> hilo; legacy-hilo
>>
>> Define a custom algorithm for generating pools of values based on a single
>> value from a table or sequence.
>>
>> These optimizers are not recommended for use. They are maintained (and
>> mentioned) here simply for use by legacy applications that used these
>> strategies previously.
>>
>> Will these settings be supported long-term, or are there plans to
>> deprecate/remove them?
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
6 years
Re: [hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo
by Steve Ebersole
In my opinion we really should not drop them unless we also write a
conversion for the existing I'd values in the database to account for the
new scheme the user picks. It's really just left there to allow these
legacy databases keep working
On Wed, Aug 28, 2019 at 7:09 AM Steve Ebersole <steven.ebersole(a)gmail.com>
wrote:
> In my opinion we really should not drop them unless we also write a
> conversion for the existing I'd values in the database to account for the
> new scheme the user picks. It's really just left there to allow these
> legacy databases keep working
>
> On Wed, Aug 28, 2019, 12:08 AM Gail Badner <gbadner(a)redhat.com> wrote:
>
>> Hi,
>>
>> The documentation for hibernate.id.optimizer.pooled.preferred says the
>> following:
>>
>> hilo; legacy-hilo
>>
>> Define a custom algorithm for generating pools of values based on a single
>> value from a table or sequence.
>>
>> These optimizers are not recommended for use. They are maintained (and
>> mentioned) here simply for use by legacy applications that used these
>> strategies previously.
>>
>> Will these settings be supported long-term, or are there plans to
>> deprecate/remove them?
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
6 years
Entity implementation of equals()
by Gail Badner
Hi,
I'm looking into the impact of HHH-13590.
In the test for HHH-13590, I see that the mapped superclass entity defines
equals() as:
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
...
}
Due to the bug:
* this is a Project instance;
* o is a HibernateProxy with target == this.
Because the getClass() != o.getClass(), false is returned, and that
ultimately causes the test to fail.
The fix for HHH-13590 results in comparing a Project instance with itself
(not the proxy).
I see that the documentation has a similar implementation of equals() in
"Example 111. Natural Id equals/hashCode" of [1].
In general, is it OK for equals() to require both instances to be of the
same class?
Thanks,
Gail
[1]
https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_...
6 years
hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo
by Gail Badner
Hi,
The documentation for hibernate.id.optimizer.pooled.preferred says the
following:
hilo; legacy-hilo
Define a custom algorithm for generating pools of values based on a single
value from a table or sequence.
These optimizers are not recommended for use. They are maintained (and
mentioned) here simply for use by legacy applications that used these
strategies previously.
Will these settings be supported long-term, or are there plans to
deprecate/remove them?
Thanks,
Gail
6 years
Hibernate Search 6.0.0.Alpha9 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Alpha9, a new release of the
still-in-development 6.0 branch.
This release mainly introduces correct handling of session flushing and
clearing, restores support for static sharding and upgrades to
Elasticsearch 7.3, Lucene 8.2 and Hibernate ORM 5.4.4.Final.
As an Alpha, this version is an early technology preview. Be sure to read
about it on our blog before you try it out:
https://in.relation.to/2019/08/26/hibernate-search-6-0-0-Alpha9/
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
6 years
JDK 13 is now in the Release Candidate Phase & JDK 14 build 11 is available.
by Rory O'Donnell
Hi Sanne,
*JDK 13 is now in the Release Candidate Phase
*
Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
the JDK Release Process (JEP 3) [2].
All changes require approval via the Fix-Request Process [3].
For more details, see Mark Reinhold's email to jdk-dev mailing list [4]
* Milestone Schedule:
o GAC - Aug 22, 2019
o GAR - Sept 5, 2019
o GA - Sept 17, 2019
**OpenJDK 14 *EA build 11 is now available at **http://jdk.java.net/14**
*
* These early access, open source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Release Notes
o http://jdk.java.net/14/release-notes
* JEPs targeted to JDK 14
o JEP 352 <http://openjdk.java.net/jeps/352> - Non-Volatile Mapped
Byte Buffers
* Significant changes since the last availability email:
o Build 10
+ 8226374: Restrict TLS signature schemes and named groups
+ 8227439: Turn off AOT by default
o Build 11
+ 8224974: Implement JEP 352
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B10%22%3A...>
*jpackage EA - **Build 1 (2019/8/20) *
* This is an early access build of JEP 343: Packaging Tool
<https://openjdk.java.net/jeps/343>, aimed at testing a prototype
implementation of jpackage, which is a new tool for packaging
self-contained Java applications along with a Java Runtime Environment.
* Build 1 (2019/8/20) is now available http://jdk.java.net/jpackage/
* Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net
<mailto:core-libs-dev@openjdk.java.net>
Regards,
Rory
[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years, 1 month
ConnectionObserver
by Sanne Grinovero
While refactoring some related optimisations, I noticed there's
currently no way to register a custom ConnectionObserver.
There seems to be only one implementation, which is registered by default:
- org.hibernate.internal.ConnectionObserverStatsBridge#ConnectionObserverStatsBridge
Some questions:
# Is this expected?
# Should we deprecate the SPI so to make this more explict in the
future, and possibly eventually discuss removing it?
# Since I'm working on performance optimisations, may I take advantage
currently of the fact that there's only one registered? We're
currently iterating "the list of obeservers"...
Thanks
6 years, 1 month
API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
by Sanne Grinovero
Hi all,
is this method needed?
- org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
It seems undocumented, untested, and everything compiles just fine if
I just delete it - however it seems marked as API.
But also, I suppose this should be invoked by a different thread as
the one actually running the query? Which would imply this
implementation would need to be threadsafe, but it's not.
My primary reason to explore its removal though is that this method is
in the way of some optimisations I'd like to apply to this class, so
it would be quite useful for me to be able to remove it - assuming
that it's no longer of interest to anyone else.
Thanks,
Sanne
6 years, 1 month
