Stride
by Steve Ebersole
I got an email from Atlassian this morning about the migration from HipChat
to Stride. Basically they have not gotten Stride feature-complete in terms
of HipChat which is the trigger for the mass migration. However, they are
reaching out to all waiting teams to see if any want to migrate anyway.
The list of missing features they sent me are:
1. Guest access
2. Some admin controls and compliance settings
3. Integrations with Atlassian server products (the Jira Server app is
currently in beta and coming soon) and some other popular integrations. See
all available Stride integrations
<http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a45485...>
.
4. User management via API
5. Dark mode
I am not really sure exactly what is missing WRT (2). (3) is nice-to-have,
but not blocker IMO assuming it gets added at some point.
I think (1) is the only one that is concerning. Though TBH for myself
personally, I do not think registering is a big deal.
Unless I hear otherwise, I plan on asking them to proceed with our
migration to Stride.
3 years, 9 months
AbstractStandardBasicType#getReplacement() prototype is incorrect since HHH-12054
by Guillaume Smet
Hi,
When HHH-12054 was fixed (see
https://github.com/hibernate/hibernate-orm/pull/2042/files), we took into
account the fact that original and target could be set to
LazyPropertyInitializer.UNFETCHED_PROPERTY in the
AbstractStandardBasicType#getReplacement() method whereas we haven't
changed the prototype of the method.
Meaning we expect for instance LazyPropertyInitializer.UNFETCHED_PROPERTY
to be a T, which is not the case.
This led to ClassCastException such as in
https://hibernate.atlassian.net/browse/HHH-12555 . To be honest, I'm
wondering why we don't have more of them.
We have 2 ways of fixing this issue:
1- change the getReplacement() prototype to take Object parameters and
return an Object as the originating replace() method
2- move the LazyPropertyInitializer.UNFETCHED_PROPERTY logic up to
replace() and make getReplacement() a "I'm sure everything is OK, now get
me a clone of my original object" thing.
1- will obviously break compatibility with any user type extending
AbstractStandardBasicType#getReplacement(). 2- will slightly change the
meaning of replace() and getReplacement() and might lead to subtle behavior
changes in user applications.
2- also means that we would have to override both replace() and
getReplacement() in BlobType and allegates.
I pushed a commit for 1- at
https://github.com/gsmet/hibernate-orm/commit/73e66e40f3438794375451145af...
so that you can fully grasp the issue.
Not saying it's the path we should take.
Thoughts?
--
Guillaume
3 years, 10 months
Re: [hibernate-dev] Multiple ResultSets from JDBC execution
by Steve Ebersole
Great that was actually my thought as well.
Anyone else?
On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> I think that by default we should not assume the result sets are the same.
>
> Only if we provide a certain QueryHint (JPA) or call a specific method
> (Hibernate API) should we instruct Hibernate to process all ResultSets, in
> the same way, using a single ResultSetMapping.
>
> Vlad
>
>
>
> On Fri, May 25, 2018 at 12:15 AM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> I'm not saying to have a single result over all of the result
>> types/mappings. I am questioning whether the proper interpretation is to
>> uniformly process all result sets (assuming all result sets have same
>> columns and domain results) versus one per ResultSet.
>>
>> E.g, let's say we have a ProcedureCall that returns 2 ResultSets that
>> each should return some scalar value, lets say an Integer... Would this
>> require passing 2 result set mappings (the same one twice), one per
>> ResultSet. Or should use be able to just pass one mapping and have us
>> apply that one to each ResultSet?
>>
>> I think there are cases where both might make sense.
>>
>>
>>
>> On Thu, May 24, 2018, 2:42 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>> wrote:
>>
>>> I this Hibernate forum discussion is on the same topic:
>>>
>>>
>>> https://discourse.hibernate.org/t/oracle-stored-procedure-with-multiple-o...
>>>
>>> So, if we have multiple REF_CURSOR sent back from a stored procedure,
>>> should we allow getResultList to be called multiple times, right?
>>>
>>> I don't think we should aggregate those to a single List<Object []> and
>>> allow a single getResultList call.
>>>
>>> Vlad
>>>
>>> On Wed, 23 May 2018, 15:52 Steve Ebersole, <steve(a)hibernate.org> wrote:
>>>
>>>> Execution of procedure calls, function calls and anonymous blocks can
>>>> all
>>>> lead to JDBC returning us multiple ResultSets.
>>>>
>>>> To account for this (for the first 2 anyway) JPA allows defining
>>>> multiple
>>>> ResultSetMapping references for the StoredProcesdureQuery.
>>>> Alternatively,
>>>> it allows specifying multiple "result classes". However, JPA is
>>>> silently
>>>> on how a provider is to treat these. Specifically, are these
>>>> "aggregated"
>>>> into a single "row reader"? Or do they represent individual row readers
>>>> specific to each expected ResultSet? In other words, are the ResultSets
>>>> heterogeneous or homogeneous?
>>>>
>>>> At the moment, Hibernate treats these by building a single aggregated
>>>> row
>>>> reader that it applies to reading all ResultSets. Like I said, JPA is
>>>> silent on what this "means" (and the TCK does not test it) so we are
>>>> free
>>>> to interpret this as we see fit.
>>>>
>>>> In retrospect I think the multiple ResultSetMappping case is probably
>>>> best
>>>> interpreted using the "distinct row reader per ResultSet" approach. I'm
>>>> not so convinced that is always the best interpretation of the multiple
>>>> result classes case. But I also think these should probably be handled
>>>> consistently.
>>>>
>>>> So what is everybody's preference here? Which interpretation do we
>>>> pick?
>>>> Worth it to make this configurable (per-SF + per-Query)?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>
3 years, 11 months
JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell
Hi Sanne,
**JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses,
is now available at **http://jdk.java.net/11**. **
*
* Newly approved Schedule, status & features
o http://openjdk.java.net/projects/jdk/11/
* Release Notes:
o http://jdk.java.net/11/release-notes
* Summary of changes
o http://jdk.java.net/11/changes
*Notable changes in JDK 11 EA builds since last email:*
* b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627>
- Kerberos sequence number issues
* b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146>
- Removal of appletviewer launcher
o deprecated in JDK 9 and has been removed in this release
* b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793>
- java.lang.ref.Reference does not support cloning
**
**
JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)
330: Launch Single-File Source-Code Programs
<http://openjdk.java.net/jeps/330>
JEPs targeted to JDK 11, so far
309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
318: Epsilon: A No-Op Garbage Collector
<http://openjdk.java.net/jeps/318>
320: Remove the Java EE and CORBA Modules
<http://openjdk.java.net/jeps/320>
321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
323: Local-Variable Syntax for Lambda Parameters
<http://openjdk.java.net/jeps/323>
324: Key Agreement with Curve25519 and Curve448
<http://openjdk.java.net/jeps/324>
327: Unicode 10 <http://openjdk.java.net/jeps/327>
328: Flight Recorder <http://openjdk.java.net/jeps/328>
329: ChaCha20 and Poly1305 Cryptographic Algorithms
<http://openjdk.java.net/jeps/329>
Finally, Initial TLSv1.3 implementation Released to the Open Sandbox.
Please note well: this branch is under
very active development and is not final by any means. Also note: by
releasing this code, we are not committing
a specific release or timeframe. We will continue development and fixing
bugs until the code is ready for inclusion
in the JDK. We welcome your feedback, more info [1]
Regards,
Rory
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
3 years, 11 months
Health check status API
by Sanne Grinovero
It was suggested to me that Hibernate ORM could help people developing
microservices on Kubernetes / Openshift by making "health checks"
easier.
In short, how to expose to some management API that we're being able
to connect to the database and do our usual things.
This could be done by connection pools as well but I suspect there
could be benefits in exposing this information in a unified way at an
higher level API; also on top of using ad-hoc specific connection
APIs, or Dialect specific instructions, I guess we could monitor
timeout exceptions, etc.. happening on the application sessions.
Wrote some notes on:
- https://hibernate.atlassian.net/browse/HHH-12655
Probably best to explore this in ORM first, but then Search and OGM
could expose/implement it too for their respective services?
Or maybe people would prefer to just run a query?
Thanks,
Sanne
3 years, 11 months
Unidirectional @OneToMany @JoinColumn associations
by Gail Badner
Unidirectional OneToMany associations using @JoinColumn that reference
columns that are not PK columns is not currently supported.
The JPA 2.1 documentation for @JoinTable says:
"Support for referenced columns that are not primary key columns of the
referenced table is optional. Applications that use such mappings will not
be portable."
I don't see anything in the user doc that explicitly states that Hibernate
does not support this.
Is this considered a bug?
Also, what about a unidirectional OneToMany using a @JoinColumn that
references some, but not all, of primary key columns? Hibernate does not
support that either. Should Hibernate support it since they are primary key
columns?
Thanks,
Gail
3 years, 11 months
Auto-registering the cacheable entities and collections
by Vlad Mihalcea
Hi,
While upgrading my Hibernate testing repository to 5.3, I realized that we
no longer auto-register the 2nd-level cache for entities and the
collections even if those are annotated with the Hibernate @Cache
annotation.
I noticed that the Hibernate tests have been modified and we require to
register those manually:
for ( Map.Entry<Class, String> entry : getCachedClasses().entrySet() ) {
config.put( AvailableSettings.CLASS_CACHE_PREFIX + "." +
entry.getKey().getName(), entry.getValue() );
}
for ( Map.Entry<String, String> entry : getCachedCollections().entrySet() )
{
config.put( AvailableSettings.COLLECTION_CACHE_PREFIX + "." +
entry.getKey(), entry.getValue() );
}
Now, if I don't do that, I get the following exception:
Caused by: org.hibernate.cache.CacheException: On-the-fly creation of
JCache Cache objects is not supported
[com.vladmihalcea.book.hpjp.hibernate.cache.query.QueryCacheTest$Post.comments]
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createCache(EhcacheRegionFactory.java:106)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.getOrCreateCache(EhcacheRegionFactory.java:100)
at
org.hibernate.cache.ehcache.internal.EhcacheRegionFactory.createDomainDataStorageAccess(EhcacheRegionFactory.java:71)
at
org.hibernate.cache.spi.support.RegionFactoryTemplate.buildDomainDataRegion(RegionFactoryTemplate.java:31)
at
org.hibernate.cache.internal.EnabledCaching.prime(EnabledCaching.java:108)
at
org.hibernate.metamodel.internal.MetamodelImpl.primeSecondLevelCacheRegions(MetamodelImpl.java:284)
at
org.hibernate.metamodel.internal.MetamodelImpl.initialize(MetamodelImpl.java:116)
at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:295)
at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
However, I don't even use JCache. I use "ehcache" instead.
properties.put("hibernate.cache.region.factory_class", "ehcache");
Was a JCache requirement?
Can we auto-register the entities and collections for other cache providers?
I'm worried about all those applications trying to upgrade to 5.3. Imagine
if they have hundreds of entities and collections. People will surely start
complaining if we force them to do that manually during bootstrap. More,
I'm not sure how they can do when they just bootstrap via a JPA
persistence.xml configuration file.
Vlad
3 years, 11 months
Breaking JBossStandAloneJtaPlatform backwards compatibility
by Sanne Grinovero
Hi Scott,
I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;
this breaks all existing applications using a generic "JBoss -
standalone" platform which isn't using the very latest WildFly.
I see that in many cases this type is auto-detected - and while
JBossStandAloneJtaPlatform causes an exception this is swallowed by
the HibernatePersistenceProvider as any exception is only mentioned at
debug level (line 61).
So two questions:
- could this be reverted and you introduce some new-gen
WildflyStandAloneJtaPlatform instead?
- bootstrap exceptions: may I change those to error level?
Thanks,
Sanne
3 years, 11 months
