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.
6 years, 3 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
6 years, 4 months
Message could not be delivered
by Bounced mail
The original message was received at Fri, 29 Jun 2018 06:03:38 +0800
from lists.jboss.org [154.188.185.178]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
6 years, 4 months
Provide a RegionFactory from Spring
by Henri Tremblay
Hi,
A change in the latest Spring Boot version is now setting a real class
loader when creating a JCache cache manager. Before it used to pass null.
Just like Hibernate still does.
So right now, we end up with two class managers. One for Hibernate 2nd
level cache and one for Spring cache.
We made a workaround in JHipster. You can see the full code and discussion
here
https://github.com/hibernate/hibernate-orm/pull/2351
It's not super pretty. The Hibernate region factory is instantiated from a
property using the no-args constructor. So we set the wanted class loader
to a static variable and retrieves it in the region factory implementation.
It works. But it's not pretty.
I was looking for a cleaner solution. Probably passing a Contributor to
Hibernate.
Is there a way to programmatically pass a contributor or a region factory
to Hibernate? From Spring Boot.
Thanks,
Henri
6 years, 5 months
Backport caching ValueBinders and ValueExtractors for a SqlTypeDescriptor from 6.0 to 5.x
by Steve Ebersole
Today, when either `SqlTypeDescriptor#getBinder` or
`SqlTypeDescriptor#getExtractor` are called we build/calculate the
binder/extractor each and every time. In 6.0 we added code that caches
these binders and extractors as they are requested.
IMO we should backport the idea of caching these to 5.x. Any volunteers?
The code on 6.0 is still local to my machine, but the code in general looks
like[1]:
public interface SqlTypeDescriptor {
...
<X>JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor);
@Remove
default <X> JdbcValueBinder<X> getBinder(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueBinder();
}
@Remove
default <X> JdbcValueExtractor<X> getExtractor(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return getJdbcValueMapper( javaTypeDescriptor ).getJdbcValueExtractor();
}
}
public abstract class AbstractSqlTypeDescriptor implements
SqlTypeDescriptor {
private final Map<JavaTypeDescriptor<?>,JdbcValueMapper<?>>
valueMapperCache = new ConcurrentHashMap<>();
protected <J> JdbcValueMapper<J> determineValueMapper(
JavaTypeDescriptor<J> javaTypeDescriptor,
Function<JavaTypeDescriptor<J>,JdbcValueMapper<J>> creator) {
return (JdbcValueMapper<J>) valueMapperCache.computeIfAbsent(
javaTypeDescriptor,
javaTypeDescriptor1 -> creator.apply( javaTypeDescriptor )
);
}
}
public abstract class AbstractTemplateSqlTypeDescriptor extends
AbstractSqlTypeDescriptor {
@Override
public <X> JdbcValueMapper<X> getJdbcValueMapper(BasicJavaDescriptor<X>
javaTypeDescriptor) {
return determineValueMapper(
javaTypeDescriptor,
jtd -> {
final JdbcValueBinder<X> binder = createBinder( javaTypeDescriptor );
final JdbcValueExtractor<X> extractor = createExtractor( javaTypeDescriptor
);
return new JdbcValueMapperImpl<>( javaTypeDescriptor, this, extractor,
binder );
}
);
}
protected abstract <X> JdbcValueBinder<X>
createBinder(BasicJavaDescriptor<X> javaTypeDescriptor);
protected abstract <X> JdbcValueExtractor<X>
createExtractor(BasicJavaDescriptor<X> javaTypeDescriptor);
}
[1] In 6.0 ValueBinder is replaced by JdbcValueBinder and ValueExtractor is
replaced by JdbcValueExtractor - the new variants serve the same basic
purposes but in different ways related to the other changes in 6.0.
JdbcValueMapper is a new contract that combines a JavaTypeDescriptor
(specifically a BasicJavaDescriptor since all JDBC types are "basic"),
SqlTypeDescriptor, JdbcValueBinder and JdbcValueExtractor
6 years, 5 months
HTTPS for Bean Validation
by Emmanuel Bernard
I’ve enabled HTTPS for BV after a bit of a fight with the DNS entries. I’m planning to enforce HTTPS only in a few days.
Have all of our GH pages hosted properties moved to HTTPS?
What about the other properties?
Emmanuel
6 years, 5 months
Re: [hibernate-dev] Native SQL Queries and Parameters
by Steve Ebersole
On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.
>
In 6.0 "user-defined type" means a very different thing generally speaking.
But I mean any BasicType, which may be a Hibernate class or a user class.
>
> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.
>
But this is my point. We can support composite parameters here. The
question really is whether we want to. In SQL there is no construct like
`(col1, col2) " ?` regardless of whether col1 and col2 are PK columns or
normal columns.
Really what I am asking is how closely we want native queries to look, feel
and work like a SQL query. Otherwise it's not really "native"
> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...
>
You are talking about Hibernate's legacy criteria API which has been
deprecated for many years now and is already gone in 6. So no, I don't
want to see Jiras for that 😉
> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src...>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9...>*
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve(a)hibernate.org> wrote:
>
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types. Personally I am thinking
>> not, but wanted to get other's opinions.
>>
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values. So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> --
> Yoann Rodiere
> yoann(a)hibernate.org / yrodiere(a)redhat.com
> Software Engineer
> Hibernate NoORM team
>
6 years, 5 months
